How do you do version numbering in an agile projec

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Currently, we're using the following version numbering scheme for our C# winforms project:

"Major Release"."Minor Release"."Iteration Number"."Build Number within that Iteration"

We wanted to be able to identify the iteration number and the build number within that iteration just by looking at the version number.

In the past, we had done something like:"Major Release"."Minor Release"."Sequential Build Number from 1.0". For example, "4.0.648" would mean there were 648 builds since 1.0 - but this information is fairly useless and anecdotal, which is why we changed to reflect iterations and builds within iterations.

So considering this new agile version numbering, we now have the problem where a different product group would like to make changes in their iteration for our project. In this instance, the version number would not make sense, because their iteration and build numbers do not correspond. For example, my project's last build was 1.0.5.1 indicating the 1st build of iteration 5. Now this other project that in it's 3rd iteration would like to make changes to my project and rebuild.

How should I cope with this situation? How do you do version numbering in your agile project?

Answer 1

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.

Answer 2

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.

Answer 3

I prefer Major.Minor.Build.Revision where Build - the number of public releases, Revision - a revision from source version system

Answer 4

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.