How do you do version numbering in an agile project? [closed]

Question

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.