Project versioning is an interesting thing. I tend to suggest using something like the Apache APR guidelines (forgive the lack of links, I should have remembered to borrow one of the EVDO cards before travelling) such as the following:
Version numbers are of the form X.Y.Z such as 1.2.0,
1.0.4, 2.0.54, or whatnot. Each of the parts (X, Y and Z) have
meaning, but not the traditional major, minor, and bugfix, though it
frequently works out that way. The version numbering serves as a
guide for compatibility.
Different X versions are not compatible. This means if you start using version 2.5 and version 3.0 is released, you will need to change your code to use the new version.
Different Y versions are backwards compatible. That means that if you start development on version 1.4 and version 1.5 comes out, you can use 1.5 without changes to your code.
Different Z versions are forward compatible. That means that if you are developing against version 1.2.17 and find a nasty bug that didn't exist in version 1.2.15 you can drop in the older version without any changes to your code.
This versioning scheme is bloody nice to program against as for any version you know what you should and should not be able to do. It turns the version number into a useful piece of information which clearly conveys quite a bit. Basically, the APR folks came up with a good scheme =)
The more common idiom found in many projects is Major.Minor.Bugfix. Where backwards compatibility is preserved across Bugfix releases, there is no tracking of forward compatibility, and the choice between major and minor versions is based on how many new features, or how much new code has been put into a given release.
This system actually works pretty well when version numbers are used as part of marketing (if we ever see Firefox XP I will cry, though). It works well when the project is a standalone application, not a library to program against. In this case forward and backward compatibility isn't much of a big deal, usually.
Things get hairy in the case of tools which export a scripting API of some sort. If the project has a plugin system, it exposes scripting hooks for something like AppleScript or XUL, or if it tends to serve as both a standalone application and a library (such as the Apache HTTPD Server) I think that the APR guidelines win out again.
Just my two cents!