Question

我了解Microsoft在对其产品进行版本控制时使用此模板：Major.Minor.Build.Revision。

当“开发人员”想要表明软件发生重大变化并且无法假定向后兼容性时，更改了主要内容。也许完成了对代码的重写。

为了向后兼容，次要数字表示显着增强。

构建号是一个小变化，例如重新编译相同的源。

修订版用于修复安全漏洞，应完全可互换。 Build和Revision都是可选的。此信息基于MSDN Version Class。

您如何对项目进行版本设置以及为何以这种方式对其进行版本化？

Answer 1

请参阅：SO version number question

Answer 2

我们通常在我工作的地方做major.minor [.maintenance [.build]]，但每个项目似乎有所不同。

主要/次要与你提到的相同。对于每次构建服务器运行时的小（错误）修复和构建，维护都会增加。

Answer 3

我个人喜欢使用一个专注于项目/产品用户可以期望的向后兼容性的方案：

1.0之前：

0.0.1 =首次发布
0 .-。X =向后兼容更新
0.X.0 =向后不兼容的更新

1.0之后：

-.-。X =没有界面更改的更新
- 。X.0 =使用向后兼容的接口添加进行更新
X.0.0 =向后不兼容的更新

使用兼容性作为版本号的中心点，可以让用户更轻松地判断他们是否可以进行平滑和安全升级，尤其是当产品是库时。

Answer 4

我经常看到Xyz，其中X是发布号后的年份，yz是一年中的月份。即201是1月，发布后2年。即当产品在5月推出时，它的第一个版本号是105.明年2月发布的是202.

Answer 5

我们通常根据当前发布日期YYYY.MM.DD. *对我们的项目进行版本控制，然后我们让内部版本号自动生成，例如，如果我们今天发布了版本，它将是2008.9.26.BUILD

Answer 6

我使用major.minor.point.revision，其中point是仅修正错误的版本，修订版是存储库修订版。这很简单，效果很好。

Answer 7

我只做Major.minor。由于我是一名开发人员（偶尔提供帮助），因此大多数人都不会关心我所做的小修复。因此，当我进行一些更改/升级时，我只是迭代了次要版本，因为我添加了新功能和主要版本号。否则，就版本号而言，我只是忽略小修正（虽然我需要Subversion版本号，如果我需要自己参考）。

Answer 8

我在很多较小的项目上工作，我个人觉得这很有用。

PatchNumber.DateMonthYear

这适用于基于Web的小型工具，用户可以查看上次更新的时间以及更新的频率。

PatchNumber是已完成的版本数量，其余用于在发布时显示用户。

Answer 9

Major.minor.patch.build 补丁是修补程序或修补程序版本。

如果您可以通过SVN获取QA，则可以使用svn HEAD修订版作为内部版本号。通过这种方式，每个构建都描述了它在源代码控制方面的来源以及构建中的内容。这意味着您将拥有带有间隙的构建（1.0.0.1,1.0.0.34 ....）

Answer 10

Major.Minor.BugFix.SVNRevision

例如：3.5.2.31578

SVN版本为您提供发送给客户的非常准确的代码。你完全确定是否存在错误修正。
如果您遇到应用程序错误，它还有助于找到正确的PDB。只需匹配构建服务器上的SVN Revisions，将PDB复制到EXE位置，打开调试器，即可获得崩溃堆栈跟踪。

Answer 11

我只有一个号码。第一个版本是001。第二个版本的第三个测试版是002b3，依此类推。这只是为了个人的思想，我实际上并没有“释放”任何东西，所以这就是理论。

Answer 12

我开始使用伪相似格式作为Ubuntu： Y.MMDD

这有助于以下几个原因：

更容易检查版本要求： if（version＆lt; 8.0901） die / exit / etc。 ;
可以在构建过程中自动生成

在第二点（ruby＆amp; rake）：

def serial(t)
   t = Time.now.utc if not t.instance_of?(Time)
   t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end

serial(Time.now)     #=> 8.0926
serial(Time.now.utc) #=> 8.0927

注意： t.strftime（“％Y。％m％d”）。to_f - 2000 遇到浮点不准确： 8.09269999999992

Answer 13

我曾经喜欢Nantucket在80年代对Clipper编译器进行版本化的方式：

Clipper Winter 1984 Clipper Summer 1985年 Clipper Winter 1985年 Clipper Autumn 1986年 Clipper Summer 1987

哦，覆盖......

[泪流满面]

你如何对你的项目进行版本化？

13 个答案: