使用什么版本编号方案？

我正在寻找一个版本编号方案来表达变化的程度，尤其是兼容性。使用什么版本编号方案？

Apache APR，例如，使用众所周知的版本编号方案

<major>.<minor>.<patch> 
example: 4.5.11

Maven的建议类似，但更为详细的架构：

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732

凡被定义Maven的版本控制方案？是否有限定符和内部编号的约定？可能使用maven但不遵循Maven版本方案是一个糟糕的主意......

你知道哪些其他版本编号方案？你更喜欢什么方案？为什么？

来源

2010-01-12 deamon

会http://stackoverflow.com/questions/1889615/version-numbering-basics帮助吗？ – VonC 2010-01-12 11:22:24

这里是current Maven version comparison algorithm和它的discussion。只要版本只是增长，并且除了内部版本号之外的所有字段都是手动更新的，那么您就很好。限定符的工作方式如下：如果其中一个是另一个的前缀，则更长一些。否则，它们按字母顺序进行比较将它们用于预发布。

借用语义版本化来表达兼容性;主要用于非向后兼容的更改，次要用于向后兼容的功能，补丁用于向后兼容的错误修正。记录它，以便您的图书馆用户可以正确表达对图书馆的依赖关系。你的快照是自动的，不必增加这些，除了因为比较前缀的方式而在发布之后的第一个快照之外。

来源

2010-01-12 11:27:55 Tobu

我会推荐Semantic Versioning标准，Maven版本控制系统也会遵循这个标准。请看看，

http://semver.org/

总之它是<major>.<minor>.<patch><anything_else>，并可以作为似乎适合你添加其他规则的任何其他部分。例如。 -<qualifier>-<build_number>。

来源

2010-01-12 11:37:37 sixohsix

- - Maven的方案似乎并不完全匹配semver.org recommondation。 semver.org：“一个特殊的版本号可以通过在补丁版本后紧跟一个任意的字符串**来表示，字符串必须只包含字母数字加破折号[0-9A-Za-z-]和**必须以字母字符[A-Za-z] **开始。“ – deamon 2010-01-12 19:12:19

@deamon semver.org可能在几年前改变了它，但为了记录它现在符合maven方案：“预发布版本可以通过在补丁版本后立即追加连字符和一系列点分隔标识符来标识。必须仅包含ASCII字母数字和连字符[0-9A-Za-z-]。标识符不能为空。数字标识符不得包含前导零。“ – Kapep 2014-11-30 15:26:21

@kapep：格式仍不完全兼容，因为比较算法来自semver比Maven使用的要复杂得多。但如果你坚持只是“-RC1”，“-RC2”或类似的，你应该没问题。 – sleske 2015-11-13 08:39:43

阅读的文章很多/质量检查/常见问题/书籍后，我变得想是[MAJOR] [MINOR]。[REV]是最有用的版本架构描述的项目版本之间的兼容性（版本架构为开发人员，不用于营销）。

主要变化是落后的不兼容，需要更改项目名称，路径文件的GUID等

MINOR变化是向后兼容。马克介绍新的功能。

REV安全/错误修复。向后和向前兼容。

通过的libtool版本语义灵感此版本的架构和文章：

http://www106.pair.com/rhp/parallel.html

注：我还建议提供编译/日期/自定义/质量作为附加信息（建号，生产日期，客户名称，发布质量）：

您好应用v2.6.34为国家银行，2011-05-03，公测，建立

但是这个信息是不版本信息！

来源

2011-10-11 18:24:00 gavenkoa

纯粹的完整性，我会提old Apple standard for version numbers。这看起来像主版本。 小版本。 错误版本。阶段。 非版本修订版。第一阶段是从集合d（发展），一个（阿尔法），b（测试版），或FC绘制的代码（最终客户舰 - 或多或少相同的发布候选，我想）。

阶段版本和非版本修订仅用于短版本的版本。

所以，事物的第一个版本可能是1.0.0。你可能已经发布了bug修正为1.0.1，新版本（具有更多功能）为1.1，重写或主要升级为2.0。如果你想要朝着2.0.1努力，你可能会从2.0.1d1,2.0.1d2，2.0.1d153开始，或者你需要的任何东西，然后发送2.0.1a1到QA，并且在他们批准2.0.1a37之后，将2.0.1b1发送给一些愿意投注的玩家，然后在2.0.1b9在该领域存活一周后，烧录2.0.1fc1并开始获得签名。当2.0.1fc17得到足够的时候，它会变成2.0.1，并且会有很多欢乐。

这种格式已经足够标准化，以至于有一个打包的二进制格式和库中的辅助例程进行比较。

来源

2012-04-27 16:09:34

纯粹为了完整性（:-)），我想指出，恕我直言，需要为每个阶段（这个方案暗示）单独构建不是一个好主意。至少最终的QA /测试版本应该在生产中保持不变。任何行为差异都应通过配置注入。见例如[单独'调试'和'发布'生成？]（http://stackoverflow.com/questions/420343/separate-debug-and-release-builds）。 – sleske 2015-11-13 08:44:05

@sleske我不认为它确实意味着每个阶段都有独立的构建。如果您正处于beta测试阶段，那么您将在dev中创建1.2.3b4，通过CI放置它，让QA批准它，执行UAT，然后将其推广到Beta测试人员，一直使用相同的二进制文件。相反，它意味着在任何时候，你都知道构建可能会走多远 - 所以你知道你什么时候提交它只会用于开发，发送给beta测试者，发布等等。转换时有一些重复例如，如果1.2.3b10通过beta测试，相同的代码可能会变成1.2.3fc1，这并不理想。 – 2015-11-15 10:56:15

请注意，版本号方案（如x.y.0与x.y）可能受到外部因素的限制。

考虑到announcement for Git 1.9 (Januaury 2014)：

候选发布版的Git V1.9-RC2现在可以在平时的地方测试。

我听到传言说，各种第三方工具不喜欢两位数的版本号（例如，“混帐2.0”），并开始barfing左右当用户安装V1.9-RC1 。
虽然它试图在他们笑自己马虎的假设，我也很实用，不介意调用即将发布v1.9.0帮助他们。

如果我们走这条路（和我倾向于走在这时，路径），版本控制方案将是：

下一个候选发布版将是v1.9.0-rc3，不v1.9-rc3;

第一维护版本为v1.9.0将v1.9.1（和第N个一个是v1.9.N）;和

v1.9.0之后的功能版本将为v1.10.0或v2.0.0，具体取决于我们正在查看的功能跳跃有多大。

来源

2014-02-04 07:30:33 VonC

使用什么版本编号方案？

回答

相关问题