最佳实践：软件版本控制
有没有什么指导方针或标准的最佳实践，如何在空闲时间将您开发的软件进行版本化以获得乐趣，但仍然会被某些人使用？ 我认为有必要对这样的软件进行版本pipe理，以便您了解版本1的含义（例如修复bug，支持等）。
但是我在哪里开始版本控制？ 0.0.0？ 或0.0？ 然后如何增加数字？ 主要发布。微小变化？ 而不应该将任何版本控制系统提交给另一个版本？ 或者这只适用于高效使用的版本？
你应该从版本1开始，除非你知道你的“释放”的第一个版本在某些方面是不完整的。
至于如何增加版本，这取决于你，但使用主要的，次要的，内部编号作为指导。
没有必要将每个版本都作为另一个版本提交给源代码控制 – 确实很快就会有一个非常大的版本号。 当你向外界释放新版本时，你只需要增加版本号（以某种方式）。
所以如果你做了一个重大的改变，从版本1.0.0.0升级到版本2.0.0.0（例如你从WinForms更改为WPF）。 如果你从1.0.0.0更小更改为1.1.0.0（你添加了对png文件的支持）。 如果你做了一个小改动，那么从1.0.0.0到1.0.1.0（你修正了一些错误）。
如果你真的想得到更详细的使用最后的数字作为内部版本号会增加每个签入/提交（但我认为这太过分了）。
我会使用xyztypes的版本
x – 主要版本
y – 次要版本
z – 编号
我基本上遵循这种模式：
-
从0.1.0开始
-
当它准备就绪时，我将代码分支到源代码库中，标记为0.1.0，并创build0.1.0分支，head / trunk变成0.2.0快照或类似的东西
-
我只向主干添加新的function，但是回到修复分支，并在时间我释放它0.1.1,0.1.2，…
-
当产品被认为是function完整的并且没有重大缺陷时，我声明版本为1.0.0
-
从那时起 – 每个人都可以决定何时增加主要版本…
我使用这个规则为我的应用程序：
XYZ
哪里：
- x =主版本号，1-〜。
- y =function号码，0-9。 如果更改包含具有或不具有错误修复的新function，请增加此数字。
- z =修补程序编号，0-〜。 如果更改只包含错误修复，请增加此数字。
例：
- 对于新的应用程序，版本号以1.0.0开头。
- 如果新版本只包含错误修正，请增加修补程序编号，以使版本号为1.0.1。
- 如果新版本包含具有或不具有错误修复程序的新function，请增加function编号并将修补程序编号重置为零，以使版本号为1.1.0。 如果function号码达到9，则增加主版本号并将function和修补程序号重置为零（2.0.0等）
我们在哪里使用abcd
- 主要（增加交付给客户）
- b – 未成年人（递增到客户）
- c – 修订（增加内部版本）
- d – 构build（由巡航控制增加）
另一个ABC方法的例子是Eclipse Bundle Versioning 。 Eclipse捆绑包有一个第四部分：
在Eclipse中，版本号由四（4）个段组成：3个整数和一个名为
major.minor.service.qualifier的string。 每个细分市场都有不同的意图：
- 主要部分表示API的破坏
- 小部分表示“外部可见”的变化
- 服务部分指出错误修复和开发stream程的变化
- 限定词段表示特定的构build
还有date版本控制scheme ，例如： YYYY.MM ， YY.MM ， YYYYMMDD
这是相当丰富的，因为第一次看到了发布date的印象。 但是我更喜欢xyzscheme，因为我总是想知道产品在生命周期中的确切点（Major.minor.release）
基本的答案是“这取决于”。
您在版本控制中的目标是什么？ 很多人使用version.revision.build，只向版本发布version.revision，因为这是一个发行版，而不是dev版本。 如果您使用签入“版本”，那么你会很快发现你的版本号变大。
如果你正在规划你的项目，那么我会增加版本的修订版本，只需稍作修改，增加版本就可以对主要更改，错误修复或function/function进行修改。 如果您提供testing版或夜间版本types版本，则扩展版本以包含每个版本的版本和增量版本。
不过，在一天结束的时候，这取决于你，它必须对你有意义。
正如Mahesh所说：我会使用xyztypes的版本
x – 主要版本y – 次要版本z – 版本号
你可能想要添加一个date时间，也许而不是z。
当你有另一个版本时，你增加次要版本。 主要版本可能会保持0或1，当你真正做出重大改变时（通常当你的软件在与之前版本不兼容的地步，或者你改变了整个框架的时候）
你知道你可以随时查看别人在做什么。 开源软件倾向于允许访问他们的存储库。 例如，你可以将你的SVN浏览器指向http://svn.doctrine-project.org并查看一个真实项目使用的版本控制系统。;
版本号，标签，都在那里。
我们遵循abc的方法，如：
如果在应用程序中发生了一些重大变化，则增加“a”。 就像我们将.NET 1.1应用程序升级到.NET 3.5一样
如果有任何新的CR或增强实施一些小的变化增加'B'。
如果代码中存在一些缺陷修复，则增加'c'。
我开始在最低（非热修复）segement版本。 我不会将这个段限制为10.除非您正在跟踪构build，那么您只需要决定何时应用增量。 如果您有质量检查阶段，则可能是您将增量应用到最低段的位置，然后在通过质量检查并释放后，再将下一个段落向上。 保留主要行为/ UI更改的最高段。
如果你和我一样，你会把它变成混合的方法，以适应你软件发展的步伐。
我认为最接受的模式abc或abcd，特别是如果你有质量保证/合规性的混合。 我已经有了很多的日常版本，我放弃了主stream版本。
我不跟踪构build，所以我喜欢使用abc模式，除非涉及修补程序。 当我必须应用修补程序，然后我将参数d作为date与时间。 我采用的时间参数是d，因为在生产中真正爆炸的时候总是有几个潜在的可能。 当我正在分歧生产修复时，我只应用d段（YYYYMMDDHHNN）。
我个人不会反对va.b revc的软件scheme，其中c是YYYYMMDDHHMM或YYYYMMDD。
所有这一切说。 如果你可以阻止一个工具来configuration和运行，它将使你避免头痛的问题，不得不大声说出版本的意见方面，你可以说“使用工具”…因为在开发过程中每个人都是如此符合。
