How to develop milestones in parallel that may not be performed sequentially?

Question

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

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

However, every few stages there is an external release consisting of the previous stages. So we get something like the following:

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

Each of these steps can be developed in parallel, but they must also be QA'd in parallel. We do this by creating branches in subversion for each milestone, marked simply with the version number for the stage. The automated system independently creates each milestone and updates the application with the milestone number and revision number subversion from which the application was created. The version number is displayed noticeably in the application, so when the QA team looks at the version number, they can bind it to a specific milestone and know what should be QA'd and what should not. After the milestone passes the QA, it will be merged into the trunk, and any current development will be updated with the latest code.

However, there is an assumption (correctly) that increasing version numbers includes all previous versions. Unfortunately, the scheme described above may not occur, since one milestone may end earlier. For example, 0.3 is likely to end up to 0.1. This means that we will have an internal release of 0.3, which does not contain functionality from 0.2 or 0.1.

That's my problem. How is it reasonable for me to use the software version if several parallel releases (internal or other) can not be executed sequentially?

Answer 1

I do not think that you can, because you have conflicting goals - parallel development and successive stages.

Either you disable release 0.3 until you have filled in 0.1 and 0.2, or you have to think about another way to assign milestone numbers.

Perhaps instead of using 0.1, etc. you can name steps based on what they are, which adds clarity and eliminates confusion.

Answer 2

Since there is no real sequence for internal stages, I would prefer to keep minor version numbers for external releases, give branch names that reflect this function, and add a subversion revision to identify internal releases. Your external releases have a nice cleanliness of version 0.1, 0.2, 0.3, and the internal release 0.2.1234 makes it easy to check in Subversion what has been bundled between the external version 0.2 and this version.

Answer 3

I'm a little confused why you distinguished between branches with numbers; name each branch according to its features (for example, vehicle doors, car-steering wheel) and use the version numbers to track the progress of each branch (car doors v0.1, 0.2, etc.).

If you intend to integrate later, it will be hell if you are really, really careful; You might think how crazy management can become.