On the topic of version number designation, I personally like the way the Linux kernel is versioned. If you're not familiar with it, here's the quick and dirty. MAJOR.MINOR.PATCH. MAJOR changes when evolutionary changes have occurred. MINOR level has a special meaning. Odd numbered MINOR levels signify an unstable or development version. Even numbered MINOR levels signify a stable or production version. The PATCH level is simply that, an interation of the significant branch.
That being said, the release of CVS changes could easily be 1.0.5. The
new development branch would be 1.1.0. When you decide that the
development branch is ready for a release, signify it by bumping the
minor number to an even 1.2.0.
It's a fairly simple and quite familiar way of managing version numbers,
one I use on my own projects. It's really nice asking someone who
complains about "production" code going through "major changes" the
following question.
"What version are you running?"
"1.3.14, why?"
"Because, that's development code. The current stable release,
that which is recommended for production use, is 1.2.34. The
version numbering is a well documented policy. Please refer to the
FAQ if you're unfamiliar with it. I would suggest you use that
version unless you wish to help debug the development version."
"But 1.3.14 has FEATURE that I really need."
"I'm glad you like the new FEATURE. Understand, though, that
you cannot rightly complain about it not working as expected. You
can, however, help us debug the code..."
$0.02,
--
Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Get my public key, ICQ#, etc. $(mailx -s 'get info' [EMAIL PROTECTED])
msg00766/pgp00000.pgp
Description: PGP signature
