What version number scheme for poorly planned, branched, and schizophrenic application

Question

I'm looking for a version numbering scheme/pattern/system for an application that is currently branched into several versions with shell game style release dates. This has made versioning a nightmare. I'd like to just use the typical Major.Minor.Revision however this will break down for me quickly the way things are presently run around here.

Here is my inventory...

• 1.0.0 - Production version.
• 1.0.1 - Production revision version with bug fixes.
• 1.1.0 - Production minor version with new features due in July (regulations compliance, must be done).
• 1.2.0 - Production minor version with new features to integrate with not-yet-released-still-under-development System A.
• 2.0.0 - Development major version "2.0" of the product (code migrated to newer platform, usability improved).

And to make it more fun, they are planning another project (new features) for integration with a different system.

• 1.3.0 - Production minor version with new features integrating with System B.

Adding to the complexity is the fact that we don't know exactly when (read: the order in which) these will "go live". If one of the systems we are integrating with gets delayed, then management changes the release schedule. So version 1.2.0 today could get delayed and then the build we tagged as 1.3.0 would drop first. Coordinating with QA is difficult enough already without changing version labels at the end of the cycle.

Questions? Thoughts? Small furry animals?

peace|dewde

Answer 1

Sounds to me like you don't want to use version numbers specifically. You can use codenames, (Windows did this with each of their releases before they were released). You basically need something more than numbers to distinguish in house which branch you are talking about. As the versions are released you can slap a Major.Minor.Revision stamp on them, but until then you need to name them in a way that will be recognizable.

Split them into branches and sub-branches. Make sure that anything dependant on a higher branch has a derivative name. So, you could call a branch ProductionMac, and a branch ProductionWindows, and that way you would know instantly that they are not to be merged, and that they both derive from production.

The most important thing to maintain is the structural hierarchy. Version numbers do this fairly well, but you have to keep adding "." for each new layer, which is annoying and completely undescriptive (much like naming your variables variableOne,variableTwo,variableThree) So, make sure that however you choose to label each branch, it is still obvious which branches are related to which other branches.

Answer 2

Sounds like numbers aren't going to help much, I'd go with naming the releases after small furry animals.

Or, name each release after the project that spawned it ('UI overhaul', 'June maintenance' etc), and then only assign it a version number when it goes live?