目前,我们正在为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'.
它适用于这样一种观念,即开发是作为连续的一系列冲刺完成的,直到业务具有他们需要的所有功能(实际上从未发生过 - 总有更多他们想要的东西).企业主理解它,开发人员可以沟通它,它自然地借助于我们的持续发展模式.