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”： 最終的發布版。