In the past I've talked about starting projects, but one thing which is often overlooked in software projects is versioning the outputs. Clearly by now you are all version-control afficionados, but those of you using DVCSs of various kinds know that the "numbers" given to you by those systems are not suitable for using as version numbers. But while you might know that instinctively, do you have a good grasp of why it's not a good idea?

Version numbers communicate a number of potential datapoints to observers. These data include, but are not limited to, the relative newness of a release, its difference relationship with predecessors, when the release was made, what kind of release it is (alpha, beta, 'golden' etc). Of course, you can communicate an awful lot more in a version number, such as exactly what revision was built, or who built it, or where it was built if you so choose.

When I number releases, I attempt to communicate a difference-to-previous-releases metric and a type-of-change metric in the form of a "major" and "minor" version number pair (e.g. 1.1) and sometimes I extend to a third "patch" number if I'm making a release which really is just a bugfix (rare, not because I write bug-free code but rather because I tend to already have made other changes and don't have the user-base which would demand a patch release). I also try and make sure that packaging systems such as Debian's can understand my version numbers. I stick to a numbering scheme compatible with how dpkg compares version numbers because of my preference for not making life harder for Debian developers.

What matters is that: of the not inconsiderably bountious, immensely ample, myriad approaches that there are to select from; you should be as consistent and careful as you can be with numbering your software releases. Be aware that there are many possible consumers of your version numbers -- developers, users, packaging systems, and marketers to name but a few.