我了解Microsoft在对其产品进行版本控制时使用此模板:Major.Minor.Build.Revision。
当“开发人员”想要表明软件发生重大变化并且无法假定向后兼容性时,更改了主要内容。也许完成了对代码的重写。
为了向后兼容,次要数字表示显着增强。
构建号是一个小变化,例如重新编译相同的源。
修订版用于修复安全漏洞,应完全可互换。 Build和Revision都是可选的。此信息基于MSDN Version Class。
您如何对项目进行版本设置以及为何以这种方式对其进行版本化?
答案 0 :(得分:8)
答案 1 :(得分:7)
我们通常在我工作的地方做major.minor [.maintenance [.build]],但每个项目似乎有所不同。
主要/次要与你提到的相同。对于每次构建服务器运行时的小(错误)修复和构建,维护都会增加。
答案 2 :(得分:4)
我个人喜欢使用一个专注于项目/产品用户可以期望的向后兼容性的方案:
1.0之前:
1.0之后:
使用兼容性作为版本号的中心点,可以让用户更轻松地判断他们是否可以进行平滑和安全升级,尤其是当产品是库时。
答案 3 :(得分:2)
我经常看到Xyz,其中X是发布号后的年份,yz是一年中的月份。即201是1月,发布后2年。即当产品在5月推出时,它的第一个版本号是105.明年2月发布的是202.
答案 4 :(得分:2)
我们通常根据当前发布日期YYYY.MM.DD. *对我们的项目进行版本控制,然后我们让内部版本号自动生成,例如,如果我们今天发布了版本,它将是2008.9.26.BUILD
答案 5 :(得分:1)
我使用major.minor.point.revision,其中point是仅修正错误的版本,修订版是存储库修订版。这很简单,效果很好。
答案 6 :(得分:1)
我只做Major.minor。由于我是一名开发人员(偶尔提供帮助),因此大多数人都不会关心我所做的小修复。因此,当我进行一些更改/升级时,我只是迭代了次要版本,因为我添加了新功能和主要版本号。否则,就版本号而言,我只是忽略小修正(虽然我需要Subversion版本号,如果我需要自己参考)。
答案 7 :(得分:1)
我在很多较小的项目上工作,我个人觉得这很有用。
PatchNumber.DateMonthYear
这适用于基于Web的小型工具,用户可以查看上次更新的时间以及更新的频率。
PatchNumber是已完成的版本数量,其余用于在发布时显示用户。
答案 8 :(得分:1)
Major.minor.patch.build 补丁是修补程序或修补程序版本。
如果您可以通过SVN获取QA,则可以使用svn HEAD修订版作为内部版本号。通过这种方式,每个构建都描述了它在源代码控制方面的来源以及构建中的内容。这意味着您将拥有带有间隙的构建(1.0.0.1,1.0.0.34 ....)
答案 9 :(得分:1)
Major.Minor.BugFix.SVNRevision
例如:3.5.2.31578
答案 10 :(得分:0)
我只有一个号码。第一个版本是001
。第二个版本的第三个测试版是002b3
,依此类推。这只是为了个人的思想,我实际上并没有“释放”任何东西,所以这就是理论。
答案 11 :(得分:0)
我开始使用伪相似格式作为Ubuntu: Y.MMDD
这有助于以下几个原因:
在第二点(ruby& 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
答案 12 :(得分:0)
我曾经喜欢Nantucket在80年代对Clipper编译器进行版本化的方式:
Clipper Winter 1984 Clipper Summer 1985年 Clipper Winter 1985年 Clipper Autumn 1986年 Clipper Summer 1987
哦,覆盖......
[泪流满面]