Haxelib 使用一个简化的 [SemVer](http://semver.org/) 。基本形式如下： ~~~ major.minor.patch ~~~ 这些是基本的规则： * 当你打破向后兼容时，主要版本递增 ，所以旧代码不能正常使用新版本的库。 * 小版本在增加一些新的功能时递增。 * 补丁版本用于小的修复，不改变公共的API，所以不会破坏已有代码。 * 当一个小版本递增时，补丁号重设为 0 。当一个主要版本递增时，小版本号和补丁号都重设为 0 。 例子： * “0.0.1”：第一个发布版。所以主要版本号为 0 的在下一个发布版有可能发生变化 - 不承诺API的稳定性。 * “0.1.0”： 添加了一个新的功能。递增了小版本号，重设补丁号。 * “0.1.1”： 意识到新的功能是破损的。现在进行修复，所以递增了补丁号。 * “1.0.0”： 新的主要版本，所以递增了主要版本号，重设了小版本号和补丁号。承诺你的用户，在升级到2.0.0之前不会打破这个API。 * “1.0.1”： 一个小补丁 * “1.1.0”： 一个新的功能 * “1.2.0”： 另一个新的功能 * “2.0.0”： 一个新的版本，可能不兼容于 1.0 。用户应该谨慎升级。 如果这个发布版是一个预览版（Alpha，Beta 或者 候选发布版本），还可以包括一个可选的发布版本号码： ~~~ major.minor.patch-(alpha/beta/rc).release ~~~ 例子： “1.0.0-alpha”： 1.0.0的最初版本，小心使用，内容不断改变。 “1.0.0-alpha.2”： 第二个最初版。 “1.0.0-beta”： 测试版 - 内容稳定下来，但是仍有可能改变。 “1.0.0-rc.1”： 1.0.0的第一个候选发布版 - 现在不应该在添加任何更多功能了。 “1.0.0-rc.2”： 1.0.0的第二个候选发布版。 “1.0.0”： 最终的发布版。