我们如何对项目进行版本控制？
我了解Microsoft在对其产品进行版本控制时使用以下模板：Major.Minor.Build.Revision。
当"开发人员"想要表明软件发生了很大的变化并且不能假定向后兼容时，将对Major进行更改。也许已经完成了代码的重大重写。
次要数字代表了向后兼容的显着增强。
内部版本号是一个很小的更改，例如，重新编译同一源。
修订版用于修复安全孔，并且应该可以完全互换。生成和修订都是可选的。此信息基于MSDN版本类。
我们如何对项目进行版本控制，以及为什么要用这种方式对项目进行版本控制？
解决方案
我使用major.minor.point.revision，其中point是一个仅修正错误的版本，修订版是存储库修订版。这很容易，而且效果很好。
我们通常在我工作的地方做major.minor [.maintenance [.build]]，但每个项目似乎有所不同。
主要/次要与我们提到的相同。每次编译服务器运行时，都会为小(错误)修复和维护而增加维护量。
看到此：SO版本号问题
我只是做Major.minor。由于我是一个开发人员(偶尔需要帮助)在一个Web应用程序上工作，所以大多数人不会在乎我所做的次要修补程序。因此，当我进行一些更改/升级时，我会在添加新功能和主要版本编号时迭代次要版本。否则，就版本号而言，我只是忽略了较小的修订(尽管如果我需要自己引用，我确实有Subversion修订版号)。
我从事许多较小的项目，而我个人发现这很有用。
PatchNumber.DateMonthYear
这是针对基于小型Web的工具，用户可以在其中查看上次更新的时间以及更新的频率。
PatchNumber是已完成的发行数量，其余版本用于在发布时向用户显示。
我经常看到Xyz，其中X是发布编号后的年份，而yz是年份的月份。 IE。 201是1月，即发布后的2年。 IE。当产品在5月发布时，其第一个发布号是105. 明年2月发布的是202.
我们通常根据当前发布日期YYYY.MM.DD. *对项目进行版本控制，并让内部版本号自动生成，例如，如果今天发布的版本号为2008.9.26.BUILD。
我只有一个号码。第一版是" 001"。第二发行版的第三个Beta是002b3，依此类推。这只是出于个人的考虑，目前我实际上还没有"发布"任何内容，因此，所有这些都是理论上的。
我个人喜欢使用一种方案，该方案侧重于项目/产品用户可以期望的向后兼容性级别：
在1.0之前：
- 0.0.1 =首次发布
- 0 .-。X =向后兼容更新
- 0.X.0 =向后不兼容的更新
1.0之后：
- -.-。X =无需界面更改即可更新
- -.X.0 =使用向后兼容的接口添加进行更新
- X.0.0 =向后不兼容的更新
使用兼容性作为版本号的中心点，使用户(尤其是在产品是库的情况下)更容易判断用户是否可以期望获得平滑且安全的升级。
Major.minor.patch.build
修补程序是修补程序或者修补程序版本。
如果我们可以通过SVN获得质量检查，并且可以在SVN上使用，则可以使用svn HEAD修订版作为内部版本号。这样，每个构建都根据源代码控制以及构建中的内容来描述其来源。这确实意味着我们将拥有差距很大的构建(1.0.0.1，1.0.0.34 ....)
我开始使用与Ubuntu类似的伪类似格式：Y.MMDD
这有几个原因：
- 更容易检查版本要求：(version <8.0901)die / exit / etc .;
- 它可以在构建过程中自动生成
在第二点(红宝石和耙子)：
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
Major.Minor.BugFix.SVN修订版
例如：3.5.2.31578
- SVN修订版为我们提供了发送给客户的非常精确的代码。我们绝对可以确定该错误修复程序是否存在。
- 如果我们遇到应用程序错误，它也有助于找到正确的PDB。只需匹配构建服务器上的SVN修订版，将PDB复制到EXE位置，打开调试器，我们就会获得崩溃堆栈跟踪。
我以前喜欢Nantucket在80年代对Clipper编译器进行版本控制的方式：
1984年冬季快船队
1985年夏天的快船
快船队1985年冬季
快船队1986年秋
快船队1987年夏季
哦，还有覆盖物...
[眼泪汪汪]
