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