Personally, I think that the release versioning I've liked the best is to do away with the whole major.minor stuff altogether. I think that this is only really feasible for internal applications, but for that, it makes life a lot easier.
Typically, if you're developing internally facing applications, I've noticed that the business never actually cares about what major/minor version they are using. Instead, they tend to want to know a) when is the next release and b) what's going to be in or out - and that's about it. Trying to keep the fact that you're working on FOO-4.34.0.1-a and BAR-3.19.4.1 when nobody cares only serves to complicate communication.
At a prior group, we didn't really have major releases other than a project kickoff. Every release was as 'major' as the prior one.
As a result, I think that they did the sensible thing and instead communicated to the business as PROJECT_RELEASENUM. The release number incremented by '1' everytime we did a release, with patches as PROJECT_RELEASENUM_PATCHNUM, which also incremented by '1'.
It works well with the notion that development is done as a continual series of sprints until the business has all of the functionality that they need (which in practice never happens - there's always something more that they want). Business owners understood it, developers could communicate it, and it lent itself naturally to the continual development model we had.
I prefer to separate the build and release process from the team development process, so I would hardly add the the iteration, sprint or similar to the version. Your case is a fine example on how having both things mixed is not easy to manage. What if you change methodology in the middle of the project (whatever the reason may be)?
Answering to you question, we've been using Scrum for two years and our version format is the classic Major.Minor.Upgrade.Build (we only use Upgrade on bugfixes). In the end it's not mandatory to use the Build number, as you only need it to disambiguate different packages from the same version, but you can use another symbol that represents some kind of Private Version.
I track the agile projects' iteration, not the software projects' iteration. If a late starter side project joins after another project it will therefore init with the current agile project iteration, and there will be no misalignment.
It should not be possible for a technical project outside of the agile project's domain to interact with a project within the domain. That would be a PM failure of the process and should be eliminated in all cases where a shared code base is in use with branching, to be patched into the trunk as a cleanup step after the project completion.
发布评论
评论（4）
就我个人而言，我认为我最喜欢的发布版本控制是完全消除整个
major.minor内容。 我认为这仅对内部应用程序真正可行，但为此，它使生活变得更加轻松。通常，如果您正在开发面向内部的应用程序，我注意到企业实际上从来不关心他们正在使用什么主要/次要版本。 相反，他们往往想知道 a) 下一个版本何时发布，以及 b) 将发布什么内容 - 仅此而已。 当无人关心时，试图保留您正在处理
FOO-4.34.0.1-a和BAR-3.19.4.1的事实只会使沟通变得复杂。在之前的小组中，除了项目启动之外，我们并没有真正发布重大版本。 每个版本都与前一个版本一样“重要”。
因此，我认为他们做了明智的事情，而是以
PROJECT_RELEASENUM的形式与业务部门进行沟通。 每次我们发布版本时，版本号都会增加“1”，补丁为PROJECT_RELEASENUM_PATCHNUM，它也会增加“1”。它很好地契合了这样的理念：开发是通过一系列连续的冲刺完成的，直到企业拥有他们需要的所有功能（这在实践中永远不会发生 - 总是有他们想要的更多东西）。 企业主理解它，开发人员可以传达它，它自然而然地适合我们的持续开发模型。
Personally, I think that the release versioning I've liked the best is to do away with the whole
major.minorstuff altogether. I think that this is only really feasible for internal applications, but for that, it makes life a lot easier.Typically, if you're developing internally facing applications, I've noticed that the business never actually cares about what major/minor version they are using. Instead, they tend to want to know a) when is the next release and b) what's going to be in or out - and that's about it. Trying to keep the fact that you're working on
FOO-4.34.0.1-aandBAR-3.19.4.1when nobody cares only serves to complicate communication.At a prior group, we didn't really have major releases other than a project kickoff. Every release was as 'major' as the prior one.
As a result, I think that they did the sensible thing and instead communicated to the business as
PROJECT_RELEASENUM. The release number incremented by '1' everytime we did a release, with patches asPROJECT_RELEASENUM_PATCHNUM, which also incremented by '1'.It works well with the notion that development is done as a continual series of sprints until the business has all of the functionality that they need (which in practice never happens - there's always something more that they want). Business owners understood it, developers could communicate it, and it lent itself naturally to the continual development model we had.
我更喜欢
Major.Minor.Build.Revision其中Build- 公开版本的数量，Revision- 来自源版本系统的修订I prefer
Major.Minor.Build.RevisionwhereBuild- the number of public releases,Revision- a revision from source version system我更喜欢将构建和发布过程与团队开发过程分开，因此我几乎不会添加迭代、冲刺或类似的版本。 你的案例就是一个很好的例子，说明了将两者混合在一起是多么不容易管理。 如果您在项目中途改变方法（无论原因是什么）怎么办？
回答你的问题，我们已经使用 Scrum 两年了，我们的版本格式是经典的 Major.Minor.Upgrade.Build（我们只在错误修复时使用 Upgrade）。 最后，并不强制使用内部版本号，因为您只需要它来消除同一版本中不同包的歧义，但您可以使用代表某种私有版本的另一个符号。
I prefer to separate the build and release process from the team development process, so I would hardly add the the iteration, sprint or similar to the version. Your case is a fine example on how having both things mixed is not easy to manage. What if you change methodology in the middle of the project (whatever the reason may be)?
Answering to you question, we've been using Scrum for two years and our version format is the classic Major.Minor.Upgrade.Build (we only use Upgrade on bugfixes). In the end it's not mandatory to use the Build number, as you only need it to disambiguate different packages from the same version, but you can use another symbol that represents some kind of Private Version.
我跟踪敏捷项目的迭代，而不是软件项目的迭代。 如果一个较晚的启动方项目在另一个项目之后加入，那么它将与当前的敏捷项目迭代一起启动，并且不会出现错位。
敏捷项目领域之外的技术项目不应该与该领域内的项目进行交互。 这将是流程的 PM 失败，并且应该在共享代码库与分支一起使用的所有情况下消除，并在项目完成后作为清理步骤修补到主干中。
I track the agile projects' iteration, not the software projects' iteration. If a late starter side project joins after another project it will therefore init with the current agile project iteration, and there will be no misalignment.
It should not be possible for a technical project outside of the agile project's domain to interact with a project within the domain. That would be a PM failure of the process and should be eliminated in all cases where a shared code base is in use with branching, to be patched into the trunk as a cleanup step after the project completion.