Date:        Tue, 15 Apr 2003 10:35:09 +0200
    From:        Martin Weber <Ephaeton@gmx.net>
    Message-ID:  <20030415083509.GR603@phaeton.entropie.net>

  | You are aware that your use of odd and even minor version numbers
  | goes straight against what is used in the GNU world ?

No, I wasn't.   That isn't something I take any notice of.

You're not the first person to point out to me that my suggestion
is similar to the scheme linux uses (I had no conscious idea of that).

  | I.e. a linux
  | release would have an even minor version, and the development would
  | have an odd minor version. Which makes more sense, too. Look at this:
  | (due to your suggestion)
  | 
  | 	release       2.1.0
  | 	development   2.0.x

No, development would be 2.2.x from before 2.1.0 was released

That is, 2.0.0 would be what would (in the current system) have been
1.6ZA (just by selecting that bump arbitrarily as the transition).

Then 2.0.1 2.0.2 ... just continues instead of 1.6ZB 1.6ZC etc.

Eventually, the next release version is branched.   In the current
numbering scheme that would get version names like 2.0alpha1 2.0alpha2
2.0beta1 2.0beta2 2.0rc1 2.0rc2 and such, and current would become 2.0A.
In my scheme the branch would just continue to be 2.0.x 2.0.x+1 (etc).
-current would at that point be switched to use  2.2.0 2.2.1 ...  (that is,
the branch would continue with the old numbering, and head would get a
new set)

When the alpha/beta/rc testing is finished (2.0.z) that version becomes
2.1.0 (and -current just continues along the 2.2.x number series until
the next release branch is made, which will (later) be 2.3, when -current
becomes 2.4.0).

I see two advantages from this kind of scheme - first there would no
longer be the letter names (1.6R type things) where only insiders
understand the relationship with the release numbering, and second,
no "negative" appendices to version numbers (2.0alpha < 2.0 etc).

And one thing I forgot in my previous message - never any exceptions
from the numbering scheme, numbers are free, if a new version number
after 1.4.3 is needed, 1.4.4 would be it, always, no 1.4.3A nonsense
to just confuse the world even more.

  | Now let's assume the first development thing was 2.2.x

The first development thing after the to-become 2.1 release was branched, yes.

  |     release      2.1.0
  |     development  2.2.x
  | 
  | Everyone coming from a GNU world will wonder why there are so many
  | release (i.e. minor version is even, 2 here) version rushing along.

Yes, that's not good.   (But keeping the status tag (RELEASE, CURRENT, etc)
available - not as a part of the version number, just present - might help
to mitigate that).

The reason I picked even for development and odd for release, is that
there's always development before a release (one hopes) and that if
we take even/odd pairs, then most commonly, the even number is less
than the odd one (one might choose to exclude 0 completely, and use {1,2}
{3,4}, ... but that's not the way computer people traditionally count).

But the risk of confusion with linux stuff does suggest that perhaps
using even for releases, and odd for development may be even less
confusing.

Once again, this is just a suggestion, out there for consideration.

kre