微软Nuget预览包版本号中第三、四段数字的具体含义是什么

你给出的nuget.org上System.Text.Json预览包版本号示例如下：

6.0.0-rc.2.21480.5  
6.0.0-rc.1.21451.13 
6.0.0-preview.7.21377.19
6.0.0-preview.6.21352.12
6.0.0-preview.5.21301.5
6.0.0-preview.4.21253.7
6.0.0-preview.3.21201.4
6.0.0-preview.2.21154.6
6.0.0-preview.1.21102.12

.NET官方预览包版本号规则解析 #

这套版本号完全符合语义化版本（SemVer）的预发布版本规范，各段含义如下：

• 前缀6.0.0是正式版的版本号，对应主版本、次版本、补丁号三个维度
• 后缀第一段的preview.n、rc.n是预发布标识+迭代号，和.NET官方公开的发布节奏对应，通常预览版每月迭代一次，RC（候选发布）版在正式发布前推出，功能基本冻结仅修复bug
• 后缀第二段的数字是构建日期标识，你猜测的“距基准日期的天数”逻辑是对的，只是这个基准日期是微软内部构建系统统一的私有基准日期，且构建完成后还要经过内部验证、签名、同步到nuget源的流程，和公开的发布日期有1-3天的时间差，所以你用发布日期倒推会出现基准不统一的情况
• 后缀第三段的数字就是当日构建序号，同一个日期触发多次构建时序号会递增，用于定位唯一的构建产物

业内主流的包版本控制策略 #

目前行业内落地比较广泛的版本控制策略有三类：

• 语义化版本（SemVer）：是绝大多数开源包、公开依赖包使用的通用标准，核心规则是主版本号变更代表不兼容的API调整，次版本号变更代表新增兼容功能，补丁号变更代表兼容的问题修复，用户仅看版本号就能判断升级风险，预发布版本可以在后缀加自定义标识
• 日期驱动版本：多用于发布周期固定的产品，比如Ubuntu的22.04代表2022年4月发布，JetBrains系列工具的2023.2代表2023年第二个大版本，优势是用户可以直观判断版本的发布时间和新旧程度
• 构建号驱动版本：多用于企业内部私有包、高频迭代的业务服务，版本号直接关联CI/CD流程的构建序号，或者搭配分支名生成，不需要人工维护版本号，迭代效率很高

微软这套版本规则的可借鉴点 #

这套方案兼顾了公开版本的可读性和内部研发的效率，有几个非常值得参考的设计：

• 预发布标识直观，普通用户仅通过preview、rc标识就能判断版本的稳定性，不需要额外查阅发布说明
• 内置构建日期和构建序号，线上出现问题时可以直接通过版本号追溯到对应的构建流程和代码提交，排查问题的效率很高
• 完全兼容语义化版本标准，所有支持SemVer的包管理器都能正确识别版本的先后顺序，不会出现依赖解析错误

内容的提问来源于stack exchange，提问作者redcalx