Over the last few years I’ve followed a build versioning strategy of the following format:
<Major Version>.<Release Version>.<Patch Number>.<Build ID>
The use of decimal points allows us to implement an auto-incrementing strategy for our builds, meaning the Build ID doesn’t need to be manually changed each time we produce a build, as this is taken care of by the build system. Both Maven and Ant have simple methods of incrementing this number.
Ensuring that each build has a unique version number (by incrementing the Build ID) allows us to distinguish between builds, as no two builds of the same project will have the same BuildID. The other numbers are changed manually, as and when required.
When to Change Versions:
Major Version – Typically changes when there are very large changes to product or project, such as after a rewrite, or a significant change to functionality
Release Version – Incremented when there is an official release of a project which is not considered a Major Version change. For example, we may plan to release a project to a customer in 2 or 3 separate releases. These releases may well represent the same major version (say version 5) but we would still like to be able to identify the fact that these are subsequent planned releases, and not patches.
Patch Number – This denotes a patch to an existing release. The release that is being patched is reflected in the Release Version. A patch is usually issued to fix a critical bug or a collection of major issues, and as such is different to a “planned” release.
Build ID – This auto-increments with each release build in the CI system. This ensures that each build has a unique version number. When the Major Version, Release Version or Patch Number is increased, the Build ID is reset to 1.
Examples:
17.23.0.9 – This represents release 17.23. It is the 9th build of this release.
17.24.0.1 – This is the next release, release 17.24. This is the first build of 17.24.
17.24.1.2 – This represents a patch for release 17.24. This is the first patch release, and happens to be the 2nd build of that patch.
DevOpsNet 
I think you should swap around the patch and the build numbers – just my personal preference.
“I think you should swap around the patch and the build numbers – just my personal preference.”
Certainly not!
Think about it, 1 patch may take a few builds before it passes all environments, (oh shoot it worked for jetty but not websphere, tweak config X and rebuild!) but it is (assuming any real CI process) an impossibility to have the same build number occur more than once.
so 1.0.0.b1, and 1.0.0.b2 could occur, and looks nice.
1.0.b1.0, and 1.0.b2.0 looks silly, and 1.0.b1.0 and 1.0.b1.1 should never happen.