[9i]版本号的命名和管理方式(Semantic Versioning)

最近在做软件程序版本的控制和管理。其中就涉及到版本号的管理。网上帖子很多，但也很混乱，需要比对何甄别。还是直接官方原文：http://semver.org/，Semantic Versioning 2.0.0

Semantic Versioning的中文翻译意思很多个， 有翻译“语义法版本控制”的，有翻译”语义法版本命名“的，也有”规范命名法“的。 

文中X，Y，Z分别表示主版本号，次版本号，补丁版本号。（x.y.Z | x > 0），意思是主版本号大于0，也就是说，该API进行过release发布的。主版本号为0时，表示是开发阶段的版本号管理。

版本号的递增原则：

1.主版本号，当有非兼容性的变更时，递增主版本号；

2.次版本号，当以可向后兼容的方式增加了功能时，递增次版本号，以及

3.补丁版本号，当有向后兼容的bug修复时，递增补丁版本号。

预发布和构建元数据的附加标签可用作主版本、次版本和补丁版的扩展。

主要正文如下：

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
一般情况下这套命名标准，是一定要发布公共的API。 API可以在代码实现或者直接存在于文档中。而且必须完成的，精确和完整的。

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically by increments of one. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
正常的版本号的形式为 X.Y.Z，其中X，Y和Z都必须是非负整数。X： 主版本，Y：次版本号，Z： 补丁版号。 XYZ每次都只能连续的增加1。 

When a major version number is incremented, the minor version and patch version MUST be reset to zero. When a minor version number is incremented, the patch version MUST be reset to zero. For instance: 1.1.3 -> 2.0.0 and 2.1.7 -> 2.2.0.
当主版本号增加1后，次版本号和补丁版号都必须设置为0。

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications must be released as a new version.
一旦打过版本的程序包release之后，将禁止修改其内容。任何后续的变更只能在新的版本上进行。

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
主版本号为0（0.y.z）是之开发的初始版本，表示其内容将会随时被改变。公共的发布版本如果也这样的话，就不能让人认为是稳定的了。

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes
版本1.0.0 表示是发布版本API了。基于该release版本号的后续版本号的递增，都说明了是基于该已发布API的升级，以及是如何升级的。

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
补丁版本号Z(x.y.Z | x > 0) 必须只能是当可向后兼容的bug修复这种情况，才能进行递增升级。

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
次版本号 Y (x.Y.z | x > 0)必须是当已发布的API有新的、可向后兼容的功能开发之后，有功能别标记为“弃用”之后，才能进行递增升级。当然在私有非发布代码有潜在的新功能开发，或者功能改进时，也可以升级次版本号。也可以包含补丁版本级的程序变更。当次版本号升级之后，补丁版本号必须设置为0。

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
主版本号X (X.y.z | X > 0)必须是当已发布的API有不向后兼容的变更发生时，才能递增升级。当然可以包含次版本号和补丁版本号的递增升级。当主版本号递增之后，次版本号和补丁版本号必须被设置成0。

A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
可以通过在补丁版本之后附加短横线和一系列点分隔标识符来表示预发布版本。标识符必须只能包含ASCII字母、数字和短横线[0-9A-Za-z-]。预发布版本满足但优先级低于关联的普通版本。

A build version MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch version or pre-release version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Build versions satisfy and have a higher precedence than the associated normal version. Examples: 1.0.0+build.1, 1.3.7+build.11.e0f985a.
build版本号可以通过在补丁版本或预发布版本之后紧跟附加加号和一系列点分隔标识符来表示。 标识符必须仅包含ASCII字母数字和短划线[0-9A-Za-z-]。 build版本满足并具有比关联的普通版本更高的优先级。 

Precedence MUST be calculated by separating the version into major, minor, patch, pre-release, and build identifiers in that order. Major, minor, and patch versions are always compared numerically. Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.
必须通过将版本分成主、次、补丁、预发布和build等标识符，并按此顺序来计算优先级。 主版本，次版本和补丁版号本总是在数字上进行比较。 必须通过如下方式比较每个点分隔标识符来确定预发布和build版本的优先级：仅对数字组成的标识符进行按数字顺序比较，将带有字母或短划线的标识符按ASCII排序顺序进行词法比较。 数字标识符的优先级总是低于非数字标识符的优先级。