你推荐什么版本的编号方案？

时间：2008-09-23 15:37:02

标签： versioning release-management sdlc

我的问题是，哪种版本命名方案应该用于什么类型的项目。

很常见的是major.minor.fix，但即使这样也可以导致4号码（即Firefox 2.0.0.16）。有些人有一个模型，奇数表示开发人员版本甚至数字稳定版本。所有类型的添加都可以进入混合，如-dev3，-rc1，SP2等。

原因是偏好一个方案而不是另一个方案，并且不同类型的项目（即开源与封闭源）是否有不同的版本命名方案？

12 个答案:

答案 0 :(得分：28)

有两个好的答案（加上很多个人偏好，请参阅Gizmo对宗教战争的评论）

对于公共应用程序，标准的Major.Minor.Revision.Build最适合IMO - 公共用户可以轻松地告诉他们所拥有的程序的版本，并且在某种程度上，可以告知过时的程度他们的版本是。

对于内部应用程序，用户从未要求提供应用程序，部署由IT处理，用户将致电帮助台，我找到了Year.Month.Day.Build在很多情况下更好地工作。因此，可以对该版本号进行解码，以便向服务台提供更有用的信息，然后提供公共版本号方案。

然而，在一天结束时，我会提出一个最重要的推荐 - 使用一个可以保持一致的系统。如果有一个系统可以设置/编写编译器以便每次都自动使用，使用。

可能发生的最糟糕的事情是你发布的二进制文件版本号与之前的版本号相同 - 我最近一直在处理自动化网络错误报告（某些应用程序），并得出了Year.Month的结论.Day.Build版本号显示在核心转储中，甚至与应用程序本身甚至不是最新的（应用程序本身使用带有实数的启动画面 - 当然，这不是从二进制中提取的，如人们所假设的那样）。结果是我无法知道崩溃转储是来自2年前的二进制文件（版本号指示的是什么）还是2个月大的二进制文件，因此无法获得正确的源代码（也没有源代码控制！ ）

答案 1 :(得分：24)

以下是我们在公司中使用的内容：主要。次要。补丁版。内部版本号。< / p>

主要更改涉及完整的发布周期，包括营销活动等。 这个数字受到R＆amp; D以外的力量的控制（例如，在我工作的一个地方，Marketing决定我们的下一个版本将是'11' - 以匹配竞争对手。我们当时的版本2 :) ）。

将新功能或主要行为更改添加到产品时，

次要会更改。

每次将补丁正式添加到版本时，

补丁版会增加一个，通常只包含错误修复。

构建版本用于为客户发布特殊版本，通常带有特定于他的错误修复。通常该修补程序将汇总到下一个补丁或次要版本（而产品管理通常会将错误标记为“将在我们的跟踪系统中发布补丁3”）。

答案 2 :(得分：23)

我是Semantic versioning

的粉丝

正如许多其他人所评论的那样，它使用了X.Y.Z格式并给出了原因。

答案 3 :(得分：22)

我们的R＆amp; D部门使用1.0.0.0.0.000:MAJOR.minor.patch.audience.critical_situation.build

请请，不要那样做。

答案 4 :(得分：15)

这种问题更多地是关于宗教战争而不是客观方面。对于编号方案或其他方案，总有很多优点和缺点。所有人可以（或应该）给你的是他们使用的方案以及他们选择它的原因。

就我而言，我使用X.Y.Z方案，所有数字都在：

  • X 表示引入向后不兼容的公共API发生了变化
  • Y 表示添加了一些功能
  • Z 表示修复（修复错误，更改内部结构而不影响功能）

最终，如果我想在正式发布之前得到用户的一些反馈，我会使用“Beta N”后缀。没有“RC”后缀，因为没有人是完美的，总会有错误; - ）

答案 5 :(得分：5)

我个人更喜欢MAJOR.MINOR.BUGFIX-SUFFIX，其中SUFFIX为dev用于开发版本（版本控制检出），rc1 / rc2用于发布候选版本，没有后缀用于发布版本

如果您有开发结帐的后缀，甚至可能使用修订号，则无需将它们变为偶数/奇数以使它们分开。

答案 6 :(得分：5)

我们更喜欢major。minor。milestone。revision - build计划，其中：

  • major：重大架构变更或功能重大进步后的增量。
  • minor：不需要更改架构的小更改和新功能。
  • milestone：表示代码的稳定性和成熟度：
    • 0 for development / pre-alpha
    • 1 for alpha
    • 2 for beta
    • 3 for release candidate（RC）
    • 4用于最终/生产发布
  • revision：表示发布，补丁或错误修正号。
  • build：对应用程序的特定版本或版本的唯一引用。构建号是一个连续的整数，通常在每次构建时递增。

示例：

  • 1.4.2.0-798：版本1.4的第一个测试版，由内部版本号798创建。
  • 1.8.3.4-970：1.8-RC4，由内部版本号970创建。
  • 1.9.4.0-986：版本1.9的第一个生产版本，由内部版本号986创建。
  • 1.9.4.2-990：版本号1.9的第二个错误修正版本，由内部版本号990创建。

由于生产版本的版本字符串的第3位数字始终为4，因此可能会删除生产版本中的数字。

答案 7 :(得分：4)

对于库，版本号会告诉您两个版本之间的兼容性级别，因此升级会有多困难。

错误修复版本需要保留二进制，源代码和序列化兼容性。

次要版本对不同的项目意味着不同的东西，但通常他们不需要保持源兼容性。

主要版本号可以打破所有三种形式。

我写了更多关于理由here。

答案 8 :(得分：3)

借助敏捷软件开发实践和SaaS应用程序，主要版本与次要版本的想法已经消失 - 版本定期出现频繁 - 因此依赖于此区别的版本编号方案不再有用对我来说。

我的公司使用编号方案，该方案采用发布开始的年份的最后2位数字，然后是该年内的版本号。

因此，2012年开始的第4版将是12.4。

您可以添加＆＃34;错误修复＆＃34;之后的版本号，如果有必要，但理想情况下你经常发布这些并不经常是必要的 - 所以＆＃34; 12.4.2＆＃34;。

这是一个非常简单的方案，并没有向我们提供我之前使用的其他版本编号方案的任何问题。

答案 9 :(得分：1)

关闭和开源版本号策略之间的差异也可以来自商业方面，而主要版本可以反映发布的年份。

答案 10 :(得分：1)

我们以前做的是 major.minor.platform.fix 。

专业：当此版本中保存的文件不再与之前版本兼容时，我们会增加此数字。
示例：3.0.0.0版中保存的文件与2.5.0.0版不兼容。

次要：我们在添加新功能时会增加此数字。用户应该看到此功能。不是开发人员的隐藏功能。当major增加时，此数字将重置为0.

平台：这是我们用于开发的平台 示例：1代表.net框架版本3.5。

修复：当此新版本中仅包含错误修复时，我们会增加此数字。当主要或次要增加时，此数字重置为0.

答案 11 :(得分：1)

简单地

Major.Minor.Revision.Build
相关问题
最新问题