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