代码版本更改“规则”

Question

代码版本更改“规则”

34

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

1) 如何正确升级版本

我有一个小软件，我一段时间前开始开发，因此我从版本0.1开始。

随着我增加更多功能，我已经不断升级次要版本号。现在我在v0.5.7（次要版本号(.5)是新功能，修订号(.7)是错误修复和小修改），问题是该程序几乎完成了，可以进行发布，但现在我“丢失”了几个次要版本号，你们如何处理这种情况？你们只是跳过数字吗？

这就带我到第二个问题。

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

我即将开始一个新项目。这次是一个不那么小的项目，而且将是公开和免费修改的，我不想遇到上述问题。那么哪个版本号是一个好的起点呢？

奖励问题：

3) 使用大于10的数字是否可以？例如v1.25或v2.2.30？

我没有看到过这种编号的软件（可能只在帮助部分或网页中显示），再次提醒我知道没有规则，但似乎有一个普遍的共识来保持版本号。

- RaptorX

3

软件版本控制不是通常所指的“版本控制”，我在这里看不到与Git有任何关系。 - CB Bailey

6

“我没有见过具有那种编号的软件” - 最新的Linux内核版本是2.6.34.1。 - Esko Luontola

是的，版本号可以任意设置，但必须是合乎逻辑的（以便追踪）。 - Vinod Srivastav

4个回答

7

在我们公司，我们采用四个令牌的版本控制概念。它的格式类似于 a.b.c.d：

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

这与我们在开发生命周期中使用的问题类型有关。我们可以一目了然地跟踪两个版本之间已完成或更改的内容。通过比较两个版本号，您可以确定已完成的问题数量和类型。更多信息，请参阅完整文档。

- csonuryilmaz

@csonuryilmaz，说得好！使用git-flow来控制这些任务怎么样？ - Gabriel Simas

感谢 @GabrielSimas。我们正在使用 redmine 进行问题/任务跟踪，并且我们有一个持续集成流水线，通过查看问题/任务来自动处理版本号。我已编辑并修复了上面的死链接，所以您可以访问获取更多信息。 - csonuryilmaz

1

Even i faced this problem with defining the version number while developing with CRM, since i wanted to deploy the same build across all the systems. I found a way to resolve it with System value + Manual + randoms.

The version information for an assembly consists of four values:

Major Version . Minor Version . Build Number . Revision

Which makes the initial Version 1.0.0.0 by default. To make more sense i replace it with

TFS Release . TFS Sprint . Change Number . Incremented build number Suppose in your TFS a single release consists 30 sprints and after that the release becomes 2, so the values for the first release will be:

TFS Release : 1

If the current sprint is 4, the TFS Sprint will have TFS Sprint : 4

Now the third part is managed by the developer, for a initial version we can have 0 which can be incremented +1 for each ChangeRequest or BugFix.

更改编号: 0 -- 表示初始版本 更改编号: 1 -- 表示更改 更改编号: 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 或者其他类似的版本号。

这种方法的好处在于你可以追踪生成代码的任务。只需要看版本号，我就能说：“嘿，这是第4个冲刺的第一个发布版本，并且进行了一些代码更改。”

- Vinod Srivastav

我不同意你的TFS示例。Scrum迭代可能会在项目开始时未计划的情况下添加功能或更改，从而在一个迭代到另一个迭代之间增加兼容性问题，并且您将面临版本控制挑战以增加主要版本以避免集成问题。语义化版本控制的想法是识别发布之间的更改以避免兼容性问题，你的想法最适合商业用途，就像微软在Windows中所做的那样，其中有一个商业版本（Win 7、Win8、Win8.1），但在内部它们具有不同的文件版本。 - Diego Mendes

我猜项目初期并没有规划功能（这几乎不可能），因为这完全取决于业务需求。如果需要一个主要功能（例如一个完整的新模块）需要20个迭代周期，那么是的，当当前版本发布后，将创建一个主要版本，版本号将增加至2.1.x.x。我无法理解你所说的集成问题。 - Vinod Srivastav

1

语义化版本控制现在几乎是实际标准。

我“丢失”了几个小版本，你们怎么处理这种情况？

你没有丢失任何版本。完全可以接受...（见下一个答案）

哪个是好的起始版本号？

这取决于人们是否在生产中使用您的代码。如果已经在生产中使用，请直接跳到v1.0.0。但是，由于你说你的代码是alpha、beta或rc（发布候选版本）质量，但你计划快速转入生产环境，考虑从v1.0.0-[alpha].N开始，其中[alpha]是软件等级，N是构建编号或其他可枚举值。

可以制作超过10的数字吗？例如v1.25或v2.2.30？

那就是这个意思。字典排序可能行不通，但没关系。

- vhs

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

版本编号政策有时可能有点疯狂（请参见版本号和JSR277，或Oracle，其Oracle Database 11g Release 2：11.2.0.1.0。
另请参见软件版本控制很荒谬）。

但是您可以从Eclipse版本号政策开始查看。
如果您真的认为需要超过三个数字，则此V.R.M.F.维护流交付工具术语解释也很有趣，但更适用于1.0之后的软件程序，其中需要修补程序和临时修复程序。

如何正确升级版本号

“现在就发布吧”：1.0.0

也被称为“1点零-零版”。至少，它已经发布了，你可以开始获得反馈并快速迭代。

哪个是一个好的起始版本号

如果主要功能还缺失，则选择0.x；如果主要功能已完成，则选择1.0.0。

是否可以使用超过10的数字？比如v1.25或v2.2.30？

可以，但我只会建议在寿命长达数年（通常是十年）的大型项目中这样做。

请注意，“正确”（虽然在语义化版本2.0.0中有详细描述）也可以受到更实际的因素的指导：

请参阅Git 1.9公告（2014年1月）：

现在可以在常规位置测试发布候选版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 之后）。
请参见 "SemVer 的下一步是什么"，以及 semver/semver/CONTRIBUTING。