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 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?

Answer 2

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 3

I'd use a dictionary to map between internal development numbers and external "release" numbers, then use the internal development numbers internally and only expose the "release" numbers when you're ready to release it out of development.

Bonus points if you use an intermediate map using irrational numbers. "How is development on release 3.14159 going?" "Oh, not bad, but I'm still fixing a bug we found in release 2.71828183." "What? That bug? That was supposed to be fixed with minor release 1.73205!" :-)

Answer 4

Based on what you describe, I agree with the first couple of posts. Meaningful, unique names relevant to the scope/feature-set are probably the way to go for each branch. Numbered versions seem reasonable within each named branch.

What you really need... is Gmail-style labeling... for your versioning!

Answer 5

As others have suggested, use a non-numeric codename internally, and apply a number as each component is released.

Appending a revision/build number to your versioning can help you match this internal codename to the external version number (and can aid in communication with QA).

For example:
RegulationCompliance r1234 corresponds to the release 1.1.0.1234.

Answer 6

nth-ing the previous posts.

We have our build system increment the build # after each build (whether or not it is to be released) which is what dev/QA uses to identify builds. The final version # is ONLY exposed to the outside world when QA releases. So there are really multiple builds of 1.3.0.x, but only one true 1.3.0.

Answer 7

Here is another alternative I considered while churning on this yesterday. Perhaps I need to rethink what is considered major. Integrating with another system may be a small quantity of work, but if it impacts the scheduling and release dates and version in such a significant way, as it does for me here, maybe that alone is a large enough impact to bump the branch up to major status. Then some of my headache would be minimized.

The most likely scenarios for releasing versions out of order revolve around the minor iterations. The major ones take a coordinated, cross-departmental effort. You can see them on the horizon. The minor ones sneak up on you and fork everything up.

"Here are the new compliance regulations. If they don't go live by July 15th, we will be fined $500,000. Per day."

"What? When did you get these?"

"Last July. Weren't you CC'd on the distribution?"

** facepalm **

I still think Devinb's answer is best. But I wanted to throw this out here for others in this dilemma.

peace|dewde