目前，我们为 C# winforms 项目使用以下版本编号方案：
“主要版本”。“次要版本”。“迭代编号”。“该迭代中的内部版本号”
我们希望能够仅通过查看版本号来识别该迭代中的迭代号和内部版本号。
过去，我们做过类似的事情：“主要版本”、“次要版本”、“1.0 的顺序内部版本号”。例如，“4.0.648”意味着自 1.0 以来有 648 次构建 - 但这些信息相当无用和轶事，这就是为什么我们改变以反映迭代和迭代内的构建。
因此，考虑到这个新的敏捷版本编号，我们现在遇到了一个问题，即不同的产品组想要在他们的迭代中为我们的项目进行更改。在这种情况下，版本号没有意义，因为它们的迭代和内部版本号不对应。例如，我的项目的最后一次构建是 1.0.5.1，表示第 5 次迭代的第一次构建。现在，在第 3 次迭代中的另一个项目想要对我的项目进行更改并重新构建。
我该如何应对这种情况？您如何在敏捷项目中进行版本编号？
我跟踪敏捷项目的迭代，而不是软件项目的迭代。如果一个较晚的启动端项目在另一个项目之后加入，它将因此与当前的敏捷项目迭代一起启动，并且不会出现错位。
敏捷项目领域之外的技术项目应该不可能与领域内的项目进行交互。这将是流程的 PM 故障，并且应该在共享代码库与分支一起使用的所有情况下消除，以便在项目完成后作为清理步骤修补到主干中。
就个人而言，我认为我最喜欢的发布版本是major.minor完全取消所有东西。我认为这仅对内部应用程序真正可行，但为此，它使生活变得更加轻松。
通常，如果您正在开发面向内部的应用程序，我注意到业务从不真正关心他们使用的主要/次要版本。相反，他们往往想知道 a) 下一个版本是什么时候，b) 什么时候发布或发布——仅此而已。试图保持你正在工作的事实，FOO-4.34.0.1-a而BAR-3.19.4.1当没有人关心时只会使沟通复杂化。
在之前的小组中，除了项目启动之外，我们并没有真正的主要版本。每个版本都与前一个版本一样“重要”。
因此，我认为他们做了明智的事情，而是以PROJECT_RELEASENUM. 每次我们发布版本时，版本号都会增加“1”，补丁为PROJECT_RELEASENUM_PATCHNUM，它也增加“1”。
它很好地适用于开发作为一系列连续冲刺完成的概念，直到业务拥有他们需要的所有功能（实际上这从未发生过 - 他们总是想要更多的东西）。企业主理解它，开发人员可以交流它，它自然而然地适用于我们拥有的持续开发模型。
我更喜欢Major.Minor.Build.Revision哪里Build- 公开发布的数量，Revision- 来自源版本系统的修订
我更喜欢将构建和发布过程与团队开发过程分开，因此我几乎不会在版本中添加迭代、冲刺或类似内容。您的案例是一个很好的例子，说明如何将这两种东西混合起来并不容易管理。如果您在项目中间更改方法（无论原因是什么）怎么办？
回答你的问题，我们已经使用 Scrum 两年了，我们的版本格式是经典的 Major.Minor.Upgrade.Build（我们只在错误修复上使用升级）。最后，使用内部版本号并不是强制性的，因为您只需要它来区分来自同一版本的不同包，但您可以使用另一个代表某种私有版本的符号。