敏捷项目中版本编号是怎么做的？我们目前正在为我们的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”，补丁也加“1”为PROJECT_RELEASENUM_PATCHNUM。它的理念是，开发是作为一系列连续的冲刺完成的，直到企业拥有他们需要的所有功能（这从未真正发生过——他们总是想要更多）。企业主理解它，开发人员可以交流它，它自然适合我们正在进行的开发模型。我更喜欢Major.Minor.Build.Revision，其中Build-公开发布的数量，Revision-源版本系统的修订我更喜欢将构建和发布过程与团队开发过程分开，所以我很难添加迭代、冲刺或类似版本。您的案例很好地说明了如何将这两件事混合在一起并不容易管理。如果您在项目中间更改方法（无论出于何种原因）怎么办？为了回答您的问题，我们已经使用Scrum两年了，我们的发布格式是经典的Major.Minor.Upgrade.Build（我们只在错误修复上使用升级）。最后，没有必要使用构建号，因为您只需要它来区分同一构建中的不同包，但您可以使用另一个符号来表示某种私有构建。以上是C#学习教程：如何在敏捷项目中进行版本编号？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
