A Nice Version Numbering System
At AdColony we eventually standardized on the following version numbering system for software releases. I'm quite happy with it and it's working out well:
Codebase.Feature.Bugfix[.ReleaseCandidate]
The most notable feature is that the true version number has four parts but we drop the fourth part for public-facing marketing and documentation. The software still uses the four-parter internally though; that's how our library identifies itself to our servers and that's what prints out in console logs.
This is done because we want to make sure that developers are always presented with a new version of our software that is always just one version number higher.
As an example, say you've been using v2.1.3 and we release v2.1.4. If you look at the console logs and see v2.1.4.0 then that means we nailed it on the first try. If you see v2.1.4.3 then that means it took 4 tries total to get something that passed Quality Assurance (often due to working around quirks on various phone hardware/OS combinations).
Here's a description of all four parts:
| Codebase | . | Feature | . | Bugfix | . | ReleaseCandidate |
|---|---|---|---|---|---|---|
| Increments after a large-scale revamp of the software or a very different architecture. Rarely changes. | Increments when one or more significant features have been added. | Increments when a release just fixes bugs that were present in the previous release or adds small new features. | Increments every time developers deliver a build to QA. |
I've just recently started numbering my Rogue language releases and will follow a similar pattern with two differences. 1) For now I'm classifying most all changes as "minor/bugfix", even fairly significant features such as debug stack tracing. Although Rogue is at or close to being production ready, it is still in rapid development with all kinds of extras being added and I don't want to "spam" the major feature number. 2) For now I'm repurposing the Release Candidate number to be an incremental development commit/feature number instead and then I'm dropping it entirely when I push a release version to the master branch.
I almost don't need the commit number at all but it helps keep me from making version number mistakes as in "did I already increment the compiler version number or do I still need to?"
As an example of my workflow, I just released v1.0.13 last night. After a small bug fix this morning I changed the compiler's version number to v1.0.14.0. After another few changes it'll be v1.0.14.3. When I'm ready to release I'll drop the .3 and push it as v1.0.14!