C# 如何在敏捷项目中进行版本编号？

目前，我们的C#winforms项目使用以下版本编号方案：

“主要版本”“次要版本”“迭代编号”“该迭代中的生成编号”

我们希望通过查看版本号就能够识别迭代编号和该迭代中的构建编号

在过去，我们做过类似的事情：“主要版本”，“次要版本”，“从1.0开始的顺序版本号”。例如，“4.0.648”意味着从1.0开始有648个构建-但是这个信息是相当无用的和轶事性的，这就是为什么我们改变以反映迭代和迭代中的构建

因此，考虑到这个新的敏捷版本编号，我们现在遇到了一个问题，即不同的产品组希望在我们项目的迭代中进行更改。在本例中，版本号没有意义，因为它们的迭代号和构建号不对应。例如，我的项目的最后一次构建是1.0.5.1，表示迭代5的第一次构建。现在，第三次迭代中的另一个项目希望对我的项目进行更改并重建

---

我应该如何应对这种情况？如何在敏捷项目中进行版本编号？

我跟踪敏捷项目的迭代，而不是软件项目的迭代。如果一个起步较晚的项目在另一个项目之后加入，那么它将与当前的敏捷项目迭代进行初始化，并且不会出现偏差

---

敏捷项目领域之外的技术项目不可能与领域内的项目交互。这将是流程的PM故障，在共享代码库与分支一起使用的所有情况下都应该消除，在项目完成后作为清理步骤修补到主干中

我更喜欢

Major.Minor.Build.Revision

其中

Build

-公开发布的数量，

Revision

-源版本系统的修订版

我更喜欢将构建和发布过程与团队开发过程分开，因此我几乎不会添加迭代、sprint或类似版本的内容。你的案例是一个很好的例子，说明如何将两者混合起来并不容易管理。如果你在项目中间改变方法论（不管原因是什么）？

---

回答您的问题，我们已经使用Scrum两年了，我们的版本格式是经典的Major.Minor.Upgrade.Build（我们只在修复错误时使用升级）。最后，不必强制使用内部版本号，因为您只需要它来消除来自同一版本的不同软件包之间的歧义，但您可以使用另一个表示某种私有版本的符号。

，我认为我最喜欢的版本控制是完全取消整个

major.minor

东西。我认为这只适用于内部应用程序，但对于这一点，它使生活变得更加轻松

通常，如果您正在开发面向内部的应用程序，我注意到业务部门实际上并不关心他们使用的是什么主要/次要版本。相反，他们往往想知道a）什么时候是下一个版本，b）什么将进入或退出-仅此而已。在没有人关心的情况下，试图保持你正在从事

FOO-4.34.0.1-a

和

BAR-3.19.4.1

工作的事实只会使沟通变得复杂

在之前的一个小组中，除了项目启动之外，我们并没有真正的主要版本。每个版本都和前一个版本一样“重要”

因此，我认为他们做了明智的事情，而是作为

PROJECT\u RELEASENUM

与企业沟通。每次我们发布一个版本时，版本号都会增加“1”，其中补丁名为

PROJECT\u RELEASENUM\u PATCHNUM

，也会增加“1”

---

它很好地支持这样一种理念，即开发是作为一系列连续的冲刺来完成的，直到业务拥有他们所需要的所有功能为止（这在实践中从未发生过——他们总是想要更多的东西）。企业主理解它，开发人员可以进行交流，它自然地适合于我们拥有的持续开发模型

敏捷开发人员没有版本号。这有点文档化的味道。他们如何跟踪版本号？很好，清晰，切中要害+1.