代码版本更改“规则”[关闭]答案

【问题标题】：Code version change "rules" [closed]代码版本更改“规则”[关闭]
【发布时间】：2011-03-23 14:27:28
【问题描述】：

我知道关于软件版本控制没有固定的规则，但我有几个问题。

1) 如何正确升级版本

我有一个不久前开始的小软件，因为我从头开始，所以我从版本 0.1 开始。

随着我添加更多功能，我一直在升级次要编号。现在我在 v0.5.7 中（新功能的次要 (.5) 和错误修复和微小更改的修订版 (.7)），问题是该程序几乎已完成分发，但现在我“失踪了“几个小版本，你们是怎么处理这种情况的？你只是跳数字吗？

这就引出了第二个问题。

2) 哪个是好的起始版本号

我即将开始一个新项目。这次可不是小项目，要公开，免费修改，我不想出现上面提到的问题。那么哪个是一个好的起点呢？

额外问题：

3) 可以使数字超过 10 吗？喜欢 v1.25 还是 v2.2.30？

我还没有看到具有这种编号的软件（可能他们只在帮助部分或他们的网页中显示它），我再次意识到没有规则，但似乎有是关于如何保留版本号的一般同意。

【问题讨论】：

软件版本控制不是通常所说的“版本控制”，我在这里看不到与 git 有任何关系。
“我没见过有这种编号的软件”——最新的Linux内核版本是2.6.34.1
是的，版本可以是任何你想要的，但必须是合乎逻辑的。

标签： version-control project-management

【解决方案1】：

版本编号策略有时可能有点疯狂（请参阅 Version numbers and JSR277 或 Oracle，及其 Oracle Database 11g 第 2 版：11.2.0.1.0。
另见Software Versioning is Ridiculous)。

但您可以先将Eclipse Version Number policy 作为一个好的开始。
如果你真的认为你需要超过三位数，这个V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation 也很有趣，但对于 1.0 后的软件更是如此，其中修复包和临时修复是按顺序排列的。

1/“已经发货”：1.0.0

也称为“1.oh-oh”版本。至少，它已经存在，您可以开始获得反馈并进行迭代快速。

2/ 0.x 如果主要功能仍然缺失； 1.0.0 是否有主要功能。

3/ 是的，但我会说只适用于寿命超过几年（通常是十年）的大型项目

请注意，“正确”（虽然在Semantic Versioning 2.0.0 中进行了详细描述）也可以由更务实的因素来指导：

见announcement for Git 1.9 (Januaury 2014)：

一个候选版本 Git v1.9-rc2 现在可以在通常的地方进行测试。

我听说各种第三方工具不喜欢两位数的版本号（例如“Git 2.0”）开始左右吐槽当用户安装 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，具体取决于我们看到的功能跳跃有多大。

2019 年 2 月更新：semver 本身即将发展（同样，在 semver2 之后）。
请参阅“What’s next for SemVer”和semver/semver/CONTRIBUTING。

【讨论】：

semver.org ：语义版本控制，是一个有趣的来源。
语义版本控制是关于版本控制 API，而不是程序。
@PolymorphicPotato 我觉得人们经常忘记，如果你声明任何公共方法或函数，你已经为你刚刚编写的代码声明了一个 api。通常，这些内部使用的 api 可能不会被视为一流的 api，它们与本身没有公共 api 的较大应用程序捆绑在一起，但该应用程序作为一个整体可能仍然是版本化的。我个人认为语义版本适用于应用程序。此外，人们通常使用术语 API 来指代且仅指 REST API。 :\

【解决方案2】：

Semantic Versioning 现在几乎是事实。

我“缺少”了几个小版本，你们如何处理这种情况？

您没有缺少版本。这是完全可以接受的……（见下一个答案）

哪个是好的起始版本号

取决于人们是否在生产中使用您的代码。如果它已经在生产中使用，请直接跳转到v1.0.0。但是，既然您说您的代码是 alpha、beta 或 rc（候选版本）质量，但您计划快速投入生产，请考虑以v1.0.0-[alpha].N 开头，其中[alpha] 是软件等级，N 是内部版本号或其他可枚举值。

数字大于 10 可以吗？喜欢 v1.25 还是 v2.2.30？

就是这样。字典排序可能不起作用，但没关系。

【讨论】：

【解决方案3】：

在我们公司，我们使用四个令牌版本控制概念。这有点像 a.b.c.d 种类：

(major).(feature).(revision).(bug/refactoring)

这与我们在开发生命周期中使用的问题类型有关。我们可以一目了然地跟踪两个以下版本之间所做的或更改的内容。通过比较以下两个版本号，您可以确定已完成问题的数量和类型。欲了解更多信息，full documentation is here.

【讨论】：

@csonuryilmaz，好点子！并使用 git-flow 来控制这些任务？
感谢@GabrielSimas。我们使用 redmine 进行问题/任务跟踪，并且我们有一个持续集成管道，通过查看问题/任务自动处理版本号。我已经编辑并修复了上面的死链接，因此您可以访问以获取更多信息。

【解决方案4】：

即使我在使用 CRM 开发时也遇到了定义版本号的问题，因为我想在所有系统中部署相同的构建。我找到了一种使用系统值 + 手动 + 随机数来解决它的方法。

程序集的版本信息由四个值组成：

主要版本 . 次要版本。 内部版本号。修订

默认情况下初始版本为 1.0.0.0。为了更有意义，我将其替换为

TFS 发布。 TFS 冲刺。 更改号码。 内部版本号增加

假设在您的 TFS 中，一个版本包含 30 个 sprint，之后版本变为 2，因此第一个版本的值将是：

TFS 发布：1

如果当前 sprint 为 4，则 TFS Sprint 将有

TFS 冲刺：4

现在第三部分由开发人员管理，对于初始版本，我们可以有 0，对于每个 ChangeRequest 或 BugFix 可以增加 +1。

Change Number：0 -- 代表初始版本 Change Number：1——代表变化 更改编号r: 2 -- 表示错误修复

虽然对于每个错误修复，代码都可能会发生变化，因此它表示代码更改为默认值。但更有意义的是，您可以用奇数表示更改，用偶数表示错误修复。

最后一部分是默认编号，幸好 .Net 允许我们使用 * 来放置默认版本号。如果其他人重新构建它，它会随着每次提供签名标记的编译/构建而不断增加。

如何实施：

打开 Properties 文件夹中的 AssemblyInfo.cs 并注释 AssemblyFileVersion，这将使 AssemblyFileVersion 和 AssemblyVersion 相同。

// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

所以最终的版本会是：1.4.2.4512什么的

这种方法的好处是您可以跟踪为其生成代码的任务。只需查看版本号，我就可以说：“嘿，它是 sprint 4 的第 1 版，并且有一些代码更改。

【讨论】：

我不同意您的 TFS 示例。 Scrum 迭代可能会增加一个 sprint 与另一个 sprint 之间的兼容性问题，以包含项目开始时未计划的功能或更改，并且您将面临增加主要版本以避免集成问题的版本控制挑战。语义版本控制的想法是识别版本之间的更改以避免兼容性问题，您的想法最适合商业目的，就像微软对 windows 所做的那样，您拥有商业版本（Win 7、Win8、Win8.1）但在引擎盖他们有不同的文件版本。
我猜这些功能在项目开始时没有计划（几乎不是真的），因为这完全取决于业务需求。如果需要 20 个 sprint 的主要功能（一个完整的新模块），那么是的，这将创建主要版本，在当前版本之后增加到 2.1.x.x。我无法理解您所说的集成问题。