在开始新开发之前或标记发行版之前，请突出版本，哪个更好？

一些项目在启动新开发项目之前会更改版本，而其他项目在标记发布时会更改版本。

哪种方法更好？

如果在新阶段开始时未更改版本号，则开发人员可能会忘记更改它，而只是发布程序。

如果在发布标记之前更改了版本号，则2个版本号（标记和Makefile / AssemblyInfo.cs）不匹配。

git describe 如果当前版本是在v1.2.3.4之后，则可能会给您v1.2.3.4-15-g1234567，但您已经将文件更改为具有v1.2.3.5

存在版本号的主要原因是，这样，当发现错误时，您可以使用错误实际发生的源代码的实际版本进行调试（从而找到错误的真正原因）。

只要产品的用户可以向开发人员传达足够的信息，开发人员就可以实现此目标，那么使用哪种版本控制方案都没有关系。

版本控制的其他原因是营销和帮助（有时是法律）团队。
这些团队拥有自己的版本优先级。

• 帮助
  想要一种简单的方法来确定兼容性和功能以及潜在的稳定性（请参阅Linux奇/偶数方案）。
• 营销
  每次都希望有更大的数量（最好在2以上）
• Legal
  希望在增加数量之前确保您拥有所有功能。

在所有情况下，使用的方案都不重要。只要您保持一致（或者可以轻松获得有关含义变化的详细文档）。

当使用像.NET程序集那样的四段版本号时，我更喜欢使用版本控制标签来设置前三段，然后第四段是自该标记以来的提交次数。

例如，一个版本被标记为“ v1.2.3”。如果git-describe返回“ v1.2.3-4-g1a2b3c4”，则在构建时，该程序集的版本为1.2.3.4。

如果以后将标签应用于该版本，git-describe则将返回“ v1.2.4”，代表版本1.2.4.0。然后，下一个提交将是1.2.4.1。

我从该系统中发现的好处是：

• 每次提交都会自动增加版本号。
• 只需标记一个版本即可将其发布为“ .0”。
• 尽管不是完美的，但该系统可与DVCS一起使用，因为它可以计算自最近标记以来的提交次数。