How to version milestones developed in parallel that may not be completed sequentially? [closed]

Question

I am currently working on a project with five other developers and we are using subversion for our revision control system. We have established that we have 12 milestones leading up to the first release of our software. We have labeled the milestones using version numbers (0.1 through 0.12) and descriptive labels. For example:

• 0.1 - Navigation
• 0.2 - Searching
• 0.3 - User Management

However, every several milestones there is an external release that is composed of the previous milestones. So, we would end up with something like the following:

• 0.1 - Navigation
• 0.2 - Searching
• 0.3 - User Management
• 0.4 - Alpha 1

Each of these milestones can be developed in parallel, but they also need to be QA'd in parallel too. We are doing this by making branches in subversion for each milestone labeled simply with the version number for the milestone. An automated system builds each milestone independently and version the application with the milestone number and the subversion revision number from which the application was built. The version number is displayed prominently in the application so that when a QA team looks at the version number they can tie it to a particular milestone and know what needs to be QA'd and what doesn't. Once a milestone passes QA it will be merged into the trunk and any ongoing development will be updated with the latest code.

However, there is an assumption (rightly so) that an increase in version numbers includes all previous versions. Unfortunately with the scheme described above this may not happen as one milestone may finish before another. For instance, 0.3 will likely finish before 0.1. Which means we would have an internal 0.3 release that does not contain functionality from 0.2 or 0.1.

This is my problem. How do I intelligently version software when several parallel releases (internal or otherwise) may be completed non-sequentially?

Answer 1

I don't think that you can because you have conflicting goals - parallel development and sequential milestones.

Either you hold off making the 0.3 release until 0.1 and 0.2 are completed or you have to think of another way of assigning milestone numbers.

Maybe instead of using 0.1 etc. you could name the milestones based upon what they are, which adds clarity and removes the confusion.

Answer 2

Since there's no real sequence to the internal milestones, I'd prefer to keep minor version numbers for the external releases, give the branches names that reflect the feature, and add the subversion revision to identify internal releases. Your external releases get nice clean 0.1, 0.2, 0.3 versions, and an internal release of 0.2.1234 makes it easy to check in Subversion exactly what has been merged into the trunk between external release 0.2 and this release.