代码版本变更“规则" [英] Code version change "rules"

问题描述

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

1) 如何正确升级版本

我有一个小软件，我不久前开始使用，因为我从头开始，所以我从 0.1 版开始.

随着我添加更多功能，我一直在升级次要号码.现在我在 v0.5.7(用于新功能的次要 (.5) 和用于错误修复和微小更改的修订版 (.7))，问题是该程序几乎已完成分发，但现在我缺少几个小版本，你们是怎么处理的?你只是跳过数字吗?

这就引出了第二个问题.

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

我即将开始一个新项目.这次是个不小的项目，要公之于众，可以免费修改，我不想有上面提到的问题.那么哪个是一个好的起点?

奖励问题:

3) 数字大于 10 可以吗?像 v1.25 还是 v2.2.30?

我还没有看到过这种编号的软件(可能他们只在帮助部分或他们的网页中显示)，我再次知道没有相关规则，但似乎有是对如何保留版本号的普遍同意.

解决方案

版本编号策略有时可能有点疯狂(请参阅 版本号和 JSR277，或 Oracle，及其 Oracle Database 11g 第 2 版:11.2.0.1.0.
另请参阅软件版本控制很荒谬).

但您可以先将 Eclipse 版本号政策视为一个好的开始.
如果您真的认为您需要三个以上的数字，这个 V.R.M.F.维护流交付工具术语解释也很有趣，但对于 1.0 后的软件更是如此，其中修复包和临时修复是有序的.

---

1/已经发货":1.0.0

也称为1.oh-oh"；版本.至少，它就在那里，您可以开始获得反馈并快速迭代.

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

3/是的，但我只会说寿命超过几年(通常为十年)的大型项目

---

注意正确"(虽然在 Semantic Versioning 2.0.0 中有详细描述)也可以通过更实用的因素来指导:

请参阅 Git 1.9 公告(2014 年 1 月):

<块引用>

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

<块引用>

我听说各种第三方工具不喜欢两位数的版本号(例如Git 2.0")并开始左右呕吐strong> 当用户安装 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.>

I know that there are no fixed rules about software version control but I have several questions.

1) How to upgrade versions correctly

I have a small software that I started a while ago and since i started from scratch I started with version 0.1.

As I added more functionality I have been upgrading the minor number. Now I'm in v0.5.7 (minor (.5) for new functions and revision (.7) for bug fixes and minor changes), the thing is that the program is almost complete for distribution, but now I'm "missing" several minor versions, how do you guys handle that situation? do you simply just jump the numbers?

That brings me to the second question.

2) Which is a good starting version number

I am about to start a new project. This time is not that small of a project and is going to be public and free for modifying, I do not want to have the issues mentioned above. So which would be a good starting point?

Bonus question:

3) Is it ok to make numbers above 10? like v1.25 or v2.2.30?

I haven't seen software with that kind of numbering (probably they show it only in the help section or in their web-page), again I am aware that there are no rules for that but it seems to be that there is a general consent on how to keep the version numbers.

解决方案

Version numbering policies can be a bit crazy at times (see Version numbers and JSR277, or Oracle, with its Oracle Database 11g Release 2: 11.2.0.1.0.
See also Software Versioning is Ridiculous).

But you can start by looking et the Eclipse Version Number policy as a good start.
If you really think you need more than three digits, this V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation is also interesting, but more so for post 1.0 softwares, where fix pack and interim fixes are in order.

---

1/ "Ship it already": 1.0.0

Also known as the "1.oh-oh" version. At least, it is out there and you can begin to get feedback and iterate fast.

2/ 0.x if major features are still missing; 1.0.0 if the major features are there.

3/ Yes, but I would say only for large projects with a lifespan over several years (a decade usually)

---

Note that "correctly" (while being described at lenght in Semantic Versioning 2.0.0) can also be guided by more pragmatic factors:

See the announcement for Git 1.9 (Januaury 2014):

A release candidate Git v1.9-rc2 is now available for testing at the usual places.

I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. "Git 2.0") and started barfing left and right when the users install v1.9-rc1.
While it is tempting to laugh at them for their sloppy assumption, I am also practical and do not mind calling the upcoming release v1.9.0 to help them.

If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be:

• The next release candidate will be v1.9.0-rc3, not v1.9-rc3;

• The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and
• The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at.

---

Update Feb. 2019: semver itself is about to evolve (again, after semver2).
See "What’s next for SemVer", and semver/semver/CONTRIBUTING.

这篇关于代码版本变更“规则"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！