Version Numbering Schemes?

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?

Comments

My personal use of major minor patch

[A nonymous Coward]

For personal projects, I change the first number when the external protocol changes, the third number for piddling around, and the second number when I clean up enough internal stuff to start a new stretch of piddling around.

--

Build Numbers

[Detritus]

For one embedded system, I setup the makefiles to automatically increment a build number every time the system was rebuilt. The programs displayed a message during initialization that included program name, "official" version number, build number and date/time of build. I did this because of past confusion over different versions of the software with the same "official" version number.

Re:Version Numbers are Antiquated Thinking

[jfrisby]

The problem with this is that you have no way of knowing how significant a change was. Many places don't upgrade just because a new version is out. It is helpful to such shops to have version numbers that are meaningul about the depth of changes.

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 ... Possibly with alternating marjor or minor versions for development/stable releases.

-JF

Version Numbers are Antiquated Thinking

[scotpurl]

The whole concept of version numbering is antiquated. Much of it is marketing hoopla, and an attempt to equate similar but different packages by competing companies. Take Netscape staying at 4.7 forever, then announcing their next version would be version 6, with version 5 never having been available. What does it mean to me? Was there ever a version 5? Is Windows ME or Windows 2000 newer?

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 .0 releases. (If the rollout of Software Z.0 is plagued with problems, no big company would abandon it, and wholesale move its users to CompetingSoftware Z.2.) If a rollout of a new version of a product experiences problems, the company will usually have to discover work arounds, and wait for the vendor to produce fixes. Which is more painful, fixing the boat you have, or building a new fleet midstream? (bad metaphor, but it's late.)

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

[cperciva]

You should make your version numbers as complicated as possible, to drive away people who shouldn't be touching your code.

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

[StandardDeviant]

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

--