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?



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.


4 Answers 4


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.

  • Thanks for the suggestion. I wondered about YYYYMMDD (or even YYMMDD) but that's going to be the major portion that changes for our customers. So when communicating, we'll almost always be asking "Hey what version is the customer on" - minimizing that mouthful is somewhat important for us. :)
    – Chu
    Jul 7, 2011 at 15:37
  • @Chu: If you want to minimize the size of the string, encode it in hex. 20110707 becomes 132DD73, or 2011-07-07 becomes 7DB-7-07 (the "month" digit doesn't need left-padding because it will only ever be 1 digit long) if you convert the date pieces separately. It's much less intelligible, but it will take less time for people on the phone to say it. Jul 7, 2011 at 15:44
  • I'd suggest hex just for the month, and use YYMDD - e.g. for 2012-12-12 you'd use 12C12. Jul 7, 2011 at 21:43
  • @Chu, in that case, a third (release) version number is (a potential) winner, being way shorter than a date in any format. Jul 7, 2011 at 22:15
  • 1
    Other potential 5-digit alternatives could include YYDDD or YYWWD.
    – Aether
    Jul 12, 2011 at 13:23

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.


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

  • If I understand the OP correctly, 2021-11-01 would translate to 11101, not 1101. Jul 7, 2011 at 15:15
  • OP doesn't seem to say if they add an extra digit for months > 9. Jul 7, 2011 at 15:23
  • I'll clarify the question. November would be 11, Jan would be 1.
    – Chu
    Jul 7, 2011 at 15:33
  • @Chu: So really "YMDD" is more like "Y(M - only for month# > 9)MDD". Ugh... at least can you always pad the month, for consistency? Otherwise you will have an identifier string that has as variable length that's dependent on the month. Very unintuitive. Jul 7, 2011 at 15:35
  • @Frustrated, AFAIR M is more or less standard notation for "nonpadded number of month", so there is no need to make the description overly complex :-) Jul 7, 2011 at 16:59

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.