[kbuzmuii] Version numbers for release candidates, betas, alphas

Consider a policy in which software version numbers must always end in ".1".   This allows having beta version numbers that sort nicely with releases.  For example, in decreasing order:

• 57.1 = what would have previously been called released version 57
• 57.0.2.1 = release candidate 2
• 57.0.1.1 = release candidate 1
• 57.0.0.2.1 = beta 2
• 57.0.0.1.1 = beta 1
• 57.0.0.0.2.1 = alpha 2
• 57.0.0.0.1.1 = alpha 1

We use 57 as a example for a release version; real software often has a dotted digit string here.

All the releases associated with release 57 start with 57, in contrast to other schemes which might use 56.999.x as beta versions prior to 57.

Next, we consider a bugfix release coming after 57.1 and release candidates and betas prior to it:

• 57.1.1 = bugfix release 1 for 57.1
• 57.1.0.n.1 = release candidate n for bugfix 1
• 57.1.0.0.n.1 = beta n for bugfix 1
• 57.1.0.0.0.n.1 = alpha n for bugfix 1

The next bugfix release is 57.2.1 and so on.  But suppose 57.2.1 introduced a controversial new feature which people don't like (bad idea for a bugfix, but it happens), so 57.1.1 becomes the last version before a fork, acting like a major release, getting its own series of additional bugfixes, perhaps backported:

• 57.1.2.1 = bugfix 2 for 57.1.1
• 57.1.2.0.n.1 = release candidate n for bugfix 2 for 57.1.1
• 57.1.1.1 = bugfix 1 for 57.1.1
• 57.1.1.0.n.1 = release candidate n for bugfix 1 for 57.1.1
• 57.1.1 = bugfix release 1 for 57.1 that has taken on a life it's own

All of the above follows a traditional software release versioning style in which the numbering of the RCs, betas, and alphas are completely independent from each other.

But here is a different style in which RCs can have betas themselves, etc., i.e., recursive.  This versioning style requires targeting what features and bugfixes go into what releases, though that is typically required for any software development.  Here we list versions including various simultaneously active branches of development:

• infinity.20190301.1 = (active) a nightly built from trunk
• 57.1.1 = first bugfix release for 57.1 (future)
• 57.1.0.1.1 = RC 1 for 57.1.1 (future).
• 57.1.0.1.0.1.1 = beta 1 for RC 1 for 57.1.1 (future).
• 57.1.0.1.0.1.0.20190301.1 = (active) alpha 20190301 for beta 1 for RC 1 for bugfix 1 for 57.1.1 (active)  Perhaps we know 57.1 will ship with a bug, so the bugfix is already being worked on despite 57.1 not being released yet.
• 57.1 = upcoming major release (future)
• 57.0.2.1 = release candidate 2 for 57.1 (future)
• 57.0.2.0.2.1 = beta 2 for release candidate 2 for 57.1 (future)
• 57.0.2.0.2.0.20190301.1 = (active) alpha 20190301 for beta 2 for release candidate 2 for 57.1
• 57.0.2.0.1.1 = beta 1 for release candidate 2 for 57.1 (past)
• 57.0.1.1 = release candidate 1 for 57.1 (past).  Perhaps we found some big problems with this RC1, necessitating having some more rounds of beta.
• 56.9.1 = bugfix 9 for 56.1 (future)
• 56.9.0.1.0.20190301.1 = (active) alpha for bugfix 9 for 56.1.  This supports the latest released version of the software (namely 56.8.1).
• 56.8.1 = bugfix 8 for 56.1 (past).  This is the latest released version.
• 56.1 = major release "56" (past)

The general idea is, the more zeroes in a version number, the more alpha quality it is, and users just need to know this.  It is reminiscent of the adage, "don't use software with a zero in the version number". "Users just need to know this" occurs in other version schemes as well, e.g.,

• the meaning of various tags, e.g., -rc2, -alpha9
• even numbers are releases; odd numbers are development
• versions *.999.x are development

Previously, we applied the same idea to just numbers.  Then, instead of ending with .1, numbers ended invisibly with 5.

Further thought: what if instead of requiring version numbers to end with .1, we required them to end with .0, and then used the empty string as a "digit" that sorts before zero?  Version strings will be shorter, but look bizarre with multiple periods in a row.  But versions with such multiple periods are never released.

We repeat a previous example:

• infinity.20190301.0 = (active) a nightly built from trunk
• 57.1.0 = first bugfix release for 57.0 (future)
• 57.1..1.0 = RC 1 for 57.1.0 (future).
• 57.1..1..1.0 = beta 1 for RC 1 for 57.1.0 (future).
• 57.1..1..1..20190301.0 = (active) alpha 20190301 for beta 1 for RC 1 for bugfix 1 for 57.1.0 (active)  Perhaps we know 57.0 will ship with a bug, so the bugfix is already being worked on despite 57.0 not being released yet.
• 57.0 = upcoming major release (future)
• 57..2.0 = release candidate 2 for 57.0 (future)
• 57..2..2.0 = beta 2 for release candidate 2 for 57.0 (future)
• 57..2..2..20190301.0 = (active) alpha 20190301 for beta 2 for release candidate 2 for 57.1
• 57..2..1.0 = beta 1 for release candidate 2 for 57.0 (past)
• 57..1.0 = release candidate 1 for 57.0 (past).  Perhaps we found some big problems with this RC1, necessitating having some more rounds of beta.
• 56.9.0 = bugfix 9 for 56.0 (future)
• 56.9..1..20190301.0 = (active) alpha for bugfix 9 for 56.0.  This supports the latest released version of the software (namely 56.8.0).
• 56.8.0 = bugfix 8 for 56.0 (past).  This is the latest released version.
• 56.0 = major release "56" (past)

Next we permit eliding the final ".0".  This is a very special case because normally the empty string is distinct from zero.  (Side note: because we have invented a digit that comes before zero, we could start numbering betas etc at 0 instead of 1.  However this would make confusing this elision of the final zero.)

• infinity.20190301 = (active) a nightly built from trunk
• 57.1 = first bugfix release for 57 (future)
• 57.1..1 = RC 1 for 57.1 (future).
• 57.1..1..1 = beta 1 for RC 1 for 57.1 (future).
• 57.1..1..1..20190301 = (active) alpha 20190301 for beta 1 for RC 1 for bugfix 1 for 57.1 (active)  Perhaps we know 57 will ship with a bug, so the bugfix is already being worked on despite 57 not being released yet.
• 57 = upcoming major release (future)
• 57..2 = release candidate 2 for 57 (future)
• 57..2..2 = beta 2 for release candidate 2 for 57 (future)
• 57..2..2..20190301 = (active) alpha 20190301 for beta 2 for release candidate 2 for 57.1
• 57..2..1 = beta 1 for release candidate 2 for 57 (past)
• 57..1 = release candidate 1 for 57 (past).  Perhaps we found some big problems with this RC1, necessitating having some more rounds of beta.
• 56.9 = bugfix 9 for 56 (future)
• 56.9..1..20190301 = (active) alpha for bugfix 9 for 56.  This supports the latest released version of the software (namely 56.8).
• 56.8 = bugfix 8 for 56 (past).  This is the latest released version.
• 56 = major release "56" (past)

Instead of the confusing empty string, we could also use a string like PreRelease which sorts before zero: 56.9.PreRelease.1.PreRelease.20190301.  The more repetitions of PreRelease in the version, the more alpha quality it is.  Or, any string (e.g., alpha, beta, rc) with the unusual convention that all non-numeric strings sort before zero, and all non-numeric strings sort equal to each other.

Previously.