I do mostly number my versions of programs after this schema :

where MM is the major version number, mm is the minor version number and c is a character denoting the build of the release (this was more important when I still needed a compiler to compile my programs before delivery).

So the character at the end increases with every time I do a public release of the program, in fact, I have come to change it every time after a release, so it is already set for the next release :

Example: Old version: 0.99h
         New version: 0.99i
[download]

The minor number increases whenever "enough" new features have accumulated, and the fraction by which it is increased reflects this.

Example: Old version: 0.01     # First proof-of-concept
         New version: 0.20a    # First public release
[download]

An increase in the major number is only warranted when there is new central functionality which may or may not break existing scripts. An exception to this rule may be the step from a 0.x release to a 1.x release, where a 1.x release is considered to be stable enough for public consumption. The compatibility between a 1.x release and a 2.x release is possibly marginal, but maybe the 2.x release has a compatibility-mode flag.

You should also know that this numbering style differs from what the Perl people use for version numbering. Perl version numbers are of the format M.m.v, with M being the major version (5 for Perl 5, 6 for Perl 6), m is the minor Perl version (6 for Perl 5.6.1), where an even number marks the stable release and an odd number marks the experimental/development release, and v is the subversion, Microsoft would call this the number of the Service Pack installed.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

I really like the Perlish way of doing version numbering:

x.y.z, where x is the major release number, y is the minor release number, and z is the bugfix/patch count. (Recently, Perl started labelling development releases with an odd y, and production releases with an even y.) So for your example, fixing a minor output formatting bug might bring your program to 1.1.1, passing all of your tests consistently, and on all the platforms you want to support might bring it to 1.2, and adding substantial new features might bring it to 2.0.

Getting your version-control system to play nicely with this numbering system is left as an excercise.

--
:wq

It may be important for you to make the distinction between version numbers of individual modules and of the entire program. Let your source control deal with the former with something like the following, assuming you're using CVS:

$My::Package::VERSION = substr(q$Revision$, 10);
[download]

(There are lots of variations on this, just use one that works for you.)

For the latter, I'd actually recommend against what Corion mentioned -- mixing letters and numbers is a no-no for automatic version comparisons and will cause you lots of pain when dealing with CPAN. And even if you're never dealing with CPAN you might want to use some the tools that it uses to manage your own code.

My rules of thumb are:

• Don't go to version 1.0 until you have a fairly stable API
• Use hundredths as increments rather than tenths (too coarse) or thousandths (too granular). So you'd have 0.01, 0.02, 0.03... instead of 0.1, 0.2, 0.3... or 0.001, 0.002, 0.0003... This allows you to make incremental improvements while still leaving room for substantial updates (e.g., 0.41 -> 0.50).
• Incremental (+.01) updates should have roughly the same amount of change, if possible. This lets people get a feel for how often they need/want to upgrade.

Good luck

Chris
M-x auto-bs-mode

And a somewhat obscure CPAN version number bit of trivia: versions with an _ (underscore) in them are taken as `beta' versions and CPAN.pm won't list them as being newer than installed versions (See the CPAN docs for more details).

I know that RCS will replace the string $Id:$ in any (text?) files you check in with the file's RCS ID, which can be useful. I imagine that CVS has a similar automated feature.

Getting either to play nicely with the major.minor.patchlevel numbering scheme is less trival, though.

--
:wq