Are there any drawbacks to the Major.Minor.YMDD.Build version strategy?

Question

I'm trying to come up with a good version strategy to fit our specific needs. We've proposed settling on this and I wanted to ask the question to see if anyone's experience would suggest avoiding this or altering it in any way.

Here's our proposal:

Versions are released in this format: MAJOR.MINOR.YMDD.BN. Here it is broken out:

• MAJOR & MINOR are typical; we'll increase MINOR when we feel code and new feature sets warrants it; once every few months most likely. MAJOR will increase ~yearly.
• YMDD: Y will be the last digit of the current year, so "1" for 2011, "2" for 2012, etc. A non-padded month will be used to keep the number smaller (9 instead of 09 for example). DD of course is the day, padded with a zero for days under 10.
• BN: BN is the build number and increases by one anytime we make a change to a branch of the code represented by the build, for example:

If were to make a build today, our release would be version 5.0.1707.1. I release to QA today and 3 days from now QA finds that a change broke the save functionality on a page. Instead of me changing our current development code, I'd go back to the code that I used to create version 5.0.1707.1, make the fix there, then increase the BN portion of the version and would then re-release 5.0.1707.2 back to QA. In short, anytime a change is made to a branched version that isn't the active dev branch, we'd use the original version number and increase only the BN portion (even if the change happened 3 days, 3 weeks or 3 months from the initial release of that version).

Anytime we make a new release from our Active dev branch, we'd come up with a new version based on the M/D of the release using the outlined strategy. We do this once every 2-3 weeks.

Are there holes or pitfalls with this? If so, what are they?

Thanks

EDIT

To clarify one point that I didn't get out very well - Oct/Nov/Dec will be two digits, it's only the year that won't be. So 9 for Sept, 10 for Oct, 11 for Nov, etc.

Answer 1

YMDD: Y will be the last digit of the current year, so "1" for 2011, "2" for 2012, etc. A non-padded month will be used to keep the number smaller (9 instead of 09 for example).

I see one major issue with this: it breaks the natural ordering of your versions. I.e. 5.0.11001.1 (released on October 1) will come before 5.0.1930.1 (released on September 30).

Apart from this, for me, readability is more important than saving a few digits, so I would rather go with a full YYYYMMDD date format. Or alternatively, a third (release) version number instead - the release date can always be traced back from the SCM anyway.

Answer 2

I wouldn’t normally bother with the date part if you have major.minor.build: it just leads to user confusion. You can always get the date from the build number, and so long as the build number is monotonically increasing, who cares?

Opinion differs on whether you should reset the build number on a new major version. Generally, the build number resets with a new project. Whether Version 2 is a new project or just a new release depends on your internal stuff.

Answer 3

The only ones I can see:

• Using the last digit of the year could be a problem if your product lives more than 10 years.

• Using a single digit for the month: how do you distinguish between January which would be "1" under your scheme and November which would also probably be "1"?

Basically, your "YMDD" part is ambiguous, and somewhat meaningless. "1101" could be "2011-01-01" or "2021-11-01. I would fix it be changing it to "YYMMDD", it removes ambiguity and it's also a strictly increasing number (until you roll over to the next century). Yes, it's two more characters (though you could save one if you did the Month in hex, so November would be "B") but when a build number is 5.0.1707.1 vs. 5.0.110707.1, it's really not that bad. I know that in the context of the rest of the build number, it's not so bad, but still, you asked...

Answer 4

PC time may not be synchronized to the same time server. If more than one PCs build the program within a few minutes time, then the version number may not represent the order of build, which leads to confusion.