Version Numbering Schemes? 23
zburke asks: "I need to make the first release of an application but I have no idea how to tag it -- version 1, version 1.0, version 1.0.0? Is it worth trying to encode major version/minor version/bug fix into an a.b.c scheme? Microsoft's "NT 4.00 Service Pack 6a" sucks, but so does Oracle's "8.1.5.4.0". Apache has the simplest versioning I've seen, but the only thing I know about 1.3.14 is that it came after 1.3.12. Any ideas or references?" The most popular version numbering scheme stems from the <major>.<minor>.<patchlevel> scheme, and that works well enough, but what other versioning schemes can you all come up with that are different enough, but not a pain in the butt to decode?
Re:Make it as complicated as possible (Score:1)
Why version 1.0 at all? (Score:1)
Re:Version Numbers are Antiquated Thinking (Score:1)
It was. There was never a commercially available project, but Netscape released the code to the Mozilla project when it was started. The reason the next Netscape browser was called 6 was because it shared virtually no code with the Classic codebase (i.e. 4.x and 5-pre-pre-alpha).
Re:Version Numbers are Antiquated Thinking (Score:1)
If you only have release dates, you'ld end up wondering if Linux 2001-01-15 is really a better version than 2001-01-04, when in fact 2001-01-15 might be a 2.2 series kernel and the earlier release date was a 2.4.
Re:Make it as complicated as possible (Score:1)
It always annoys me... (Score:1)
*Not a Sermon, Just a Thought
*/
Just include a changelog (Score:1)
It makes it very clear what version you have and makes it easier to determine if an upgrade is available.
As far as your concern with being descriptive with your versioning scheme, most people could care less, as long as it's the "latest and greatest". In addition, if you keep with the versioning pattern that the kernel has adopted (odd/even=devel/stable), then the user knows if they have the latest "even" version, they should be good to go.
However, it's still a very good idea to keep a somewhat verbose changelog, both for your tracking purposes and the user's curiosities/requirements.
Re:Version numbers work...and work well (Score:1)
YYYY-MM-DD is an ISO standard (ISO 8601). I found a summary of it here:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html [cam.ac.uk]
One nice thing about it is that an "alphabetical" sort will order such values chronologically (in a directory listing for example).
I can't recall ever having seen YYYY-DD-MM.
Re:Make it as complicated as possible (Score:1)
Re:It always annoys me... (Score:1)
In this case 1.0.31 is more recent than 1.0.4, because the separator is the dot and not the tens, hundreds, thousands... It's either this or the dot-scheme, not both.
If if where ".3 +.01", the final result would be "1.0.3.1", which is an older version then "1.0.4".
Keep it simple (Score:1)
Re:Make it as complicated as possible (Score:2)
My variation on major.minor.patch (Score:2)
I like the major.minor.patch scheme, but I like also like to be able to tell something from the version number. Specifically, I want all releases with the same major version number to be backward compatible (stuff that worked with 4.1.x will still work with 4.2.x but may well break with 5.x.y). This equates to the following rules for assigning version numbers:
- major version numbers change when an external protocol is deleted or modified in some non-compatible way.
- minor version number change when an external protocol is added or an existing one is extended but is still compatible with the old semantics.
- patch level changes with each new build. The patch level essentially tells the user that some bugs have been (hopefully) fixed in x.y.n that weren't fixed in x.y.n-1.
Obviously this version number scheme is only really usefull for libraries and client-server systems. If your program doesn't provide an external interface then there is nothing worth keeping track of.Incidentally, for things other than libraries and servers, I agree with the posters who are saying that version numbers are an antiquated concept (or a marketing ploy) and we should just be letting CVS take care of things for us. Still, there are plenty of folks out there (myself included) who care about what version of a specific piece of software they are using, if only because they know that 3.2.25 was the first release to have the features that they wanted.
This suggests that, even if you normally rely on CVS for version control, you should tag important released with meaninfull version numbers for the convenience of users. For this purpose, however, you might as well go the route of simple sequential integers or complete date-times.
NOTE: where my version numbering scheme is meant to communicate something about the status and feature set of the finished software product, the CVS version numbering scheme is meant to communicate something about the status of the sources with respect to the development process. My versioning scheme doesn't easily support branching of the source tree, while the CVS scheme will be nearly incomprehensible to users for any project of reasonable size. This is why CVS has tags and rtags.
Consider the problem (Score:2)
So the problem that version numbers really solve is not the one of giving users a hint about how recent their installation is, but for development teams who want to be able to get something of a handle on their process. Especially for big shops that want to support older, shipped, version while continuing development on newer versions.
Thus, if your company has shipped version 2.0 of the product, one group can continue maintaining that branch, producing patches and security fixes that apply to that version, while another group works on 2.1 or 3.0 or whatever makes sense to that company. If the company has its head on straight, it will be able to merge those patches into the main development effort for the next version.
As an independent software developer, you're not likely to be supporting one version while developing the next -- you just have one code line and you fix everything "in the next release", and that's ok because you're pushing out a release whenever you feel like it.
With something like Perl and the Linux kernel, it makes sense to have even versions be product, and odd be development, because there are enough hackers out there working to apply fixes to the current release while other hackers work on the next Big Thing.
I agree that most users just want to know how old the thing they've got is, so release dates are good to have, but other than that, find something that is meaningful and useful to you.
build Number (Score:2)
Major.Minor.Build
with build being and ever increasing number (sort of like the Microsoft build numbers) Major changes with major new releases/functionality, Minor is for fixes and small feature changes
Version numbers work...and work well (Score:2)
Putting a date on a specific version is a good idea, though eliminating the traditional major.minor.(build) version scheme in favor of a date-only version doesn't really change much. Adding it to the end of the string would be helpful for managing programs.
The traditional version scheme simply works for management and development as well as savy customers -- to say nothing of open source projects. That's why it hasn't been abandoned in preference of date numbering. The full version may get burried, and a date string may be added, but I doubt it will be replaced even on a minor number of projects. Even the folks working on Wine are slowly switching from 'vintage' dates to num-dot-num releases in announcements as Wine 1.0 gets closer and closer and it becomes less erratic from release to release.
Versioning primarily by date introduces it's own issues;
Version numbers and marketing men. (Score:2)
I've worked with many pieces of software where version numbers were hiked just to keep the revenue stream coming in.
One OS had version numbers in the form major.minor.patch. The manufacturers would only activly support two revisions at a time, including connecting distint versions together, and API calls were only guaranteed to last that long. Major revisions were released 2-3 years apart, with successive minor releases being released to add new hardware support and other simillar features. Patches were released every few months, and were generally a bundle of minor patches, or occasionally a serious required bug-fix.
Then the marketing men appeared. Firstly patched releases became minor releases, making them appear more significant than they were, and were just an excuse to sell the media at extortionate prices (you could FTP the patches from the FTP site, though). Major releases seemed to appear more often, but with no real API or other significant changes, as was the case in the past. Major version numbers were just used as a ruse to force customers to upgrade, where in fact very little was changing. One major upgrade added so little that I can't recall anything about it, the previous major release only introducing a small filesystem improvement.
My personal use of major minor patch (Score:3)
--
Build Numbers (Score:3)
Re:Version Numbers are Antiquated Thinking (Score:3)
MySQL and Linux both have good version numbering methods. Perl's method, while a little absurd at times (extraneous 0's), also works well.
I wholeheatedly favor the approach of
-JF
Version Numbers are Antiquated Thinking (Score:3)
I favor describing a new release by it's release date, serializing it by year, month, then date. Even the non-technical can understand how old a release is. Patches should be points to the serialized version, so that we know which @#!! version the patch applies to. Make patches lettered, and you'll not confuse the two. Thus 19991223.d is clearly a bug fix, but not as "new" and "featured" as 20000115.a.
The actual version number is irrelevant, The age/vintage of the code, the improvements since release, and the reliability of the code when it was released are the deciding factors. Going with date-based release numbers indicates the evolution from one release to the next, and allows the vendor to avoid the marketing pressures of "new" releases at regular intervals. The product just simply improves over time.
The management aversion to adopting a ".0" release is also becoming antiquated. Few companies have the patience or capital to abandon the rollout of a "Z.0" product in favor of a competing "Z.2" product, owing to some rabbit's foot aversion to
Find a way to avoid deferring major code changes until a major release, and instead make those features available more quickly.
Make it as complicated as possible (Score:3)
Instead of using simple numbers like 1.1, 2.0, and 3.141592653, use numbers like 2.2.14, 2.3.99, or 2.4.0test12345. You'll see an immediate improvement in the number of clueless newbies who get anywhere near your code.
Another solution is to simply adopt fuzzy names. Call something 4.2-STABLE, but keep on making changes to it, so that when someone reports a bug and says they are running 4.2-STABLE, you can ask "which 4.2-STABLE?" and file the bug report under "user didn't submit enough information".
Re:Make it as complicated as possible (Score:3)
IIRC TeX is asymptotically converging on PI -- to an arbitrary but large percision -- for it's version number (trust a mathematician to come up with this). So when TeX is feature-complete for all possible uses and contains no bugs, version will exactly equal PI...
Of course it could be argued that this numbering scheme is perfect for TeX since it's just about the last possible thing a clueless newbie should be trying to use. :-)
--