Today I released two entirely different pieces of software with the identical version number 3.20120115. Debian developers also will be soon noticing a piece of software I released with the version number 9.20120115.
I expect to move more of my software to this version number scheme over time, unless I find something badly wrong with it. It reflects how I think about versions for my software; there's a kind of continual "now" that development progresses through, in which individual releases have little discrete meaning and at the same time, there can also be significant discontinuities, that require the user to do something to deal with (such as a new debhelper compat version, or a new git-annex repository format).
Those two things are really all that I need a version number for my software to communicate. I can do without the rest of the things that version numbers are used for:
- The marketing of version 1.0 and 2.0.
- The comparative nuances such as whether 1.0 to 1.1 is a relatively big change, and 1.0 to 1.0.1 is a relatively small change
- The implication that 0.99 is almost 1.0 ready, and 1.1a is some kind of alpha release.
There is so much software, with so many version numbers that any signal encoded in such version numbers is swamped in the noise. Even on projects that I develop a version number like 2.88 is meaningless to me. All I care about is, how long ago was that version? Has there been a major change breaking compatibility since that version? "2.88" doesn't answer these questions well; "3.20111111" does.
It is a little wordy to have the full year in there, and it can be annoying to remember to set the version to the right date on release day (TODO: automate). This is balanced with the version not being so wordy as to include the time of day, which means I might have to do a 3.20120115.1 if I goof up. These minor problems are worth it to instantly know how old a version is when a user pastes it into a bug report.
And that is probably all I will ever have to say about version numbers. :)
I must admit, I was quite disappointed and frustrated when I saw that debhelper also got infected by this very annoying and only hard to memorize version numbers.
With these version number scheme you can't see on a first glance if a version is the same, a higher or lower version than the one you use. Try to compare 3.20110111 with 3.20101111 or 3.20111011 without starting to count 1s, just by looking at it. This is how ikiwiki and git-annex version numbers look to me since months now: They all look the same. I can't remember anymore which version I use on which box. It's just plain annoying.
I'm sure this argument isn't "badly enough" for Joey to stop this adversity, so I have suggestion for damage mitigation: Using delimiters between YYYY, MM and DD would already help a lot to guide the eye where it has to look for each relevant token, i.e. it be easier to distinguish between 3+2011.01.11, 3+2010.11.11 and 3+2011.10.11. (I though would prefer dashes inside the date as delimiter but that doesn't work for native Debian packages as Joey uses for the mentioned software, so I used pluses for the main delimiter instead.)
Nevertheless I still prefer non-date based versioning schemes over date based version numbers.
I just used date based stuff just for packaging snapshots which have not been knowingly tagged as some release. But since I just recently have been pointed to git's describe feature, I'll likely use that for snapshots in the future, especially automatically generated snapshots. While hex git ids are not useful when continuously ascending numbers are needed, version tags in git repositories often are continuously ascending, so git describe counts the number of commits since the last tag and generates a version number out of the last tag, the number of commits and the beginning of the commit id, e.g. 0.9.4-92-gedb329a if the last tag was 0.9.4, there were 92 commits since then and the last commit is ebd329a (the g stands for git).
"Normal" non-date version numbers suck, because they don't mean anything except to the developer that came up with them. To everyone else they're an arbitrary number to compare to the other arbitrary version numbers of the same program (or package).
A date is at least something everyone can understand. It tells you the release date, but doesn't tell you anything about the maturity of the code. The irony is that this is fine, because version numbers without a date also tell you nothing about the maturity of the code. The only downside to version numbers with a date is that the version numbers are long, making them slightly harder to read. These kinds of date numbers seem like they should be easier for a computer to parse, though.
I found a pretty good web link discussing the issue here:
http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html
-- ChrisK
I might add the dots at some point. (It can only be done sanely when there's a new major version though.)
If you're manually memorizing, or comparing debhelper version numbers, you're probably doing something wrong.
The best version scheme I've ever found is the old-fashioned X.Y.Z ... BUT with these very strict rules:
What I love about this is that it tells you things like:
Anyway, just wanted to share what I think is a good idea. I've used this scheme for over a decade for internal projects at work and it is a dream. =)