Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
Related: What version naming convention do you use? –  Anna Lear Jul 12 '11 at 13:09
add comment

migrated from stackoverflow.com Jul 7 '11 at 14:58

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 6 down vote accepted

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.

share|improve this answer
    
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 '11 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. –  FrustratedWithFormsDesigner Jul 7 '11 at 15:44
    
I'd suggest hex just for the month, and use YYMDD - e.g. for 2012-12-12 you'd use 12C12. –  configurator Jul 7 '11 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. –  Péter Török Jul 7 '11 at 22:15
    
Other potential 5-digit alternatives could include YYDDD or YYWWD. –  Aether Jul 12 '11 at 13:23
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
If I understand the OP correctly, 2021-11-01 would translate to 11101, not 1101. –  Péter Török Jul 7 '11 at 15:15
    
OP doesn't seem to say if they add an extra digit for months > 9. –  FrustratedWithFormsDesigner Jul 7 '11 at 15:23
    
I'll clarify the question. November would be 11, Jan would be 1. –  Chu Jul 7 '11 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. –  FrustratedWithFormsDesigner Jul 7 '11 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 :-) –  Péter Török Jul 7 '11 at 16:59
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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