使用什么版本编号方案？

Question

我正在寻找一种表示变化程度的版本编号方案,尤其是兼容性.

例如,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版本方案是个坏主意...

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

Answer 1

这是当前的Maven版本比较算法,并对其进行了讨论.只要版本只增长,并且除了内部版本号之外的所有字段都是手动更新的,那么你就是好的.限定符的工作方式如下:如果一个是另一个的前缀,则更长的时间更长.否则按字母顺序进行比较.将它们用于预发布.

借调语义版本控制来表达兼容性; major用于非向后兼容的更改,minor用于向后兼容的功能,patch用于向后兼容的错误修正.记录它,以便您的库用户可以正确地表达对库的依赖性.您的快照是自动执行的,除了发布后的第一个快照之外,不必增加这些快照,因为前缀的比较方式.

Answer 2

我建议使用语义版本控制标准,Maven版本控制系统也会遵循该标准.请检查,

http://semver.org/

简而言之<major>.<minor>.<patch><anything_else>,您可以在其他任何部分添加其他规则,因为这些规则似乎适合您.例如.-<qualifier>-<build_number>.

Answer 3

纯粹为了完整性,我将提到版本号的旧Apple标准.这看起来像主要版本.次要版本.错误版本.阶段.非发布版本.阶段是从集合d(开发),a(alpha),b(beta)或fc(最终客户发布 - 与发布候选者或多或少相同,我认为)中抽取的代码.

阶段和非发布版本仅用于缺少正确版本的版本.

所以,第一个版本的东西可能是1.0.0.您可能已经发布了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,并且会有很多欢乐.

这种格式足够标准化,它有一个打包的二进制格式,以及库中的辅助例程,用于进行比较.