语义版本控制
2025-02-10 15:36:26 0 举报
AI智能生成
语义版本控制是一种软件版本命名和管理方案,核心内容包括主版本号(MAJOR)、次版本号(MINOR)和修订号(PATCH)。版本号的升序反映了软件更新的性质:主版本号在重大更改时递增,次版本号用于添加新功能但保持向后兼容,修订号针对 bug 修复。这种系统通常用点(.)分隔数字表示,例如:3.2.1。使用语义版本控制能清晰表述版本更新内容,便于开发者和用户理解所涉及的改变,从而有效跟踪软件的不同版本。
作者其他创作
大纲/内容
规范
使用语义版本控制的软件必须声明公共 API。
该 API 可以在代码本身中声明,也可以严格存在于文档中。
不管怎样做,它都应该是精确和全面的
该 API 可以在代码本身中声明,也可以严格存在于文档中。
不管怎样做,它都应该是精确和全面的
普通版本号必须采用 XYZ 形式,其中 X、Y 和 Z 是非负整数,并且不得包含前导零。
X 是主要版本,Y 是次要版本,Z 是补丁版本。
每个元素必须在数字上增加。
例如:1.9.0 -> 1.10.0 -> 1.11.0
X 是主要版本,Y 是次要版本,Z 是补丁版本。
每个元素必须在数字上增加。
例如:1.9.0 -> 1.10.0 -> 1.11.0
一旦版本化的软件包发布,该版本的内容就不得修改。
任何修改都必须作为新版本发布
任何修改都必须作为新版本发布
主要版本零 (0.yz) 用于初始开发。
任何事情都可能随时改变。
公共 API 不应该被认为是稳定的
任何事情都可能随时改变。
公共 API 不应该被认为是稳定的
1.0.0 版本定义了公共 API。
此版本后版本号递增的方式取决于此公共 API 及其变化方式
此版本后版本号递增的方式取决于此公共 API 及其变化方式
如果仅引入向后兼容的错误修复,则必须增加补丁版本 Z (xyZ | x > 0)。
错误修复被定义为修复不正确行为的内部更改
错误修复被定义为修复不正确行为的内部更改
如果公共 API 中引入了新的向后兼容功能,则次要版本 Y (xYz | x > 0) 必须递增。
如果任何公共 API 功能被标记为已弃用,则必须递增它。
如果在私有代码中引入大量新功能或改进,它可能会增加。
它可能包括补丁级别的更改。
当次要版本增加时,补丁版本必须重置为 0
如果任何公共 API 功能被标记为已弃用,则必须递增它。
如果在私有代码中引入大量新功能或改进,它可能会增加。
它可能包括补丁级别的更改。
当次要版本增加时,补丁版本必须重置为 0
如果公共 API 中引入了任何向后不兼容的更改,则主版本 X (Xyz | X > 0) 必须递增。
它还可能包括较小的补丁级别更改。
当主要版本增加时,补丁和次要版本必须重置为 0
它还可能包括较小的补丁级别更改。
当主要版本增加时,补丁和次要版本必须重置为 0
预发布版本可以通过在补丁版本之后附加连字符和一系列点分隔的标识符来表示。
标识符必须仅包含 ASCII 字母数字和连字符 [0-9A-Za-z-]。
标识符不能为空。
数字标识符不得包含前导零。
预发布版本的优先级低于关联的普通版本。
预发布版本表示该版本不稳定,可能无法满足其关联的正常版本所示的预期兼容性要求。
示例:1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92、1.0.0-xyz.--
标识符必须仅包含 ASCII 字母数字和连字符 [0-9A-Za-z-]。
标识符不能为空。
数字标识符不得包含前导零。
预发布版本的优先级低于关联的普通版本。
预发布版本表示该版本不稳定,可能无法满足其关联的正常版本所示的预期兼容性要求。
示例:1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92、1.0.0-xyz.--
构建元数据可以通过紧跟补丁或预发布版本后附加加号和一系列点分隔的标识符来表示。
标识符必须仅包含 ASCII 字母数字和连字符 [0-9A-Za-z-]。
标识符不能为空。确定版本优先级时必须忽略构建元数据。
因此,仅构建元数据不同的两个版本具有相同的优先级。
示例:1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85、1.0.0+21AF26D3----117B344092BD
标识符必须仅包含 ASCII 字母数字和连字符 [0-9A-Za-z-]。
标识符不能为空。确定版本优先级时必须忽略构建元数据。
因此,仅构建元数据不同的两个版本具有相同的优先级。
示例:1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85、1.0.0+21AF26D3----117B344092BD
优先级是指订购时版本之间的比较方式
必须通过按顺序将版本分为主要、次要、补丁和预发布标识符来计算优先级(构建元数据不计入优先级)
从左到右比较每个标识符时,优先级由第一个差异确定,如下所示:主要版本、次要版本和补丁版本始终按数字进行比较
示例:1.0.0 < 2.0.0 < 2.1.0 < 2.1.1
当major、minor和patch相等时,预发布版本的优先级低于普通版本
示例:1.0.0-alpha < 1.0.0
具有相同主版本、次版本和补丁版本的两个预发布版本的优先级必须通过从左到右比较每个点分隔的标识符来确定,直到发现差异
仅由数字组成的标识符进行数字比较
带有字母或连字符的标识符按 ASCII 排序顺序进行词法比较
数字标识符的优先级始终低于非数字标识符
如果所有前面的标识符都相等,则较大的预发布字段集合比较较小的集合具有更高的优先级
示例: 1.0.0-α < 1.0.0-α.1 < 1.0.0-α.β < 1.0.0-β < 1.0.0-β.2 < 1.0.0-β.11 < 1.0.0-rc.1 < 1.0.0
给定版本号 MAJOR.MINOR.PATCH递增
当您进行不兼容的 API 更改时的主要版本
当您以向后兼容的方式添加功能时的次要版本
进行向后兼容的错误修复时的补丁版本
预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展
思考
对api兼容性的分析
对消息格式的兼容性分析
工具
japicmp
revapi
0 条评论
下一页