Yeah, its more a release number. It makes sense to use a single positive integer and simply increment it every release.
Having said that, though, I quite like Semantic Versioning[1]. The advantage it has over a single incrementing counter is that you know when API compatibility changes.
Right. Think of a new version of some software that drops support for a deprecated part of an API in a minor release. I did get screwed by that happening with a Latex package, xy-pic, some years back.
Yeah. Painful. Thats the kind of thing semantic versioning aims to solve: within a major release, all minor and patch releases must maintain backwards compatibility. Patch releases may not change the API at all; minor releases may add to it but not remove things[1]. Major releases may drop backwards compatibility by removing or modifying API items. Seems like a reasonable system to me and would avoid the problem you mentioned.
[1] I guess it can deprecate things, as long as they are still available for use.
Semantic Versioning looks like a really nice solution. At the moment our internal versioning philosophy is A.C.F - adding.changing.fixing but I can see that something more robust has its uses.
Having said that, though, I quite like Semantic Versioning[1]. The advantage it has over a single incrementing counter is that you know when API compatibility changes.
[1] http://semver.org/