On Thu, Apr 24, 2003 at 03:33:06PM -0700, Bill Studenmund wrote:
  | On Fri, 25 Apr 2003, Luke Mewburn wrote:
  | 
  | > On Wed, Apr 23, 2003 at 09:55:00PM -0400, Andrew Brown wrote:
  | >   | so we're currently at 1.6R, which will lead to 2.0 (followed by 2.0.1,
  | >   | 2.0.2, etc, as needed), at which point current becomes 2.1A (followed
  | >   | by 2.1B and 2.1C, etc), and when we're ready, 2.2 gets branched, at
  | >   | which point current becomes 2.3A, etc.
  | >
  | > here's my take:
  | >
  | > when we branch 2.0, it's identification becomes "2.0_BETA1".
  | > as the branch stabilizes, it goes to
  | > 	2.0_BETA2 ...  2.0_BETAn
  | > 	2.0_RC1 ... 2.0_RCn
  | > 	2.0
  | > (this is what would happen anyway, and is what occurred in 1.6)
  | >
  | > after the time of the 2.0 branch, current becomes "3.0_ALPHA1".
  | > when we need a bump for kernel bump in current, crank to 3.0_ALPHA2, (etc)
  | 
  | Uhm, when was that announced? I know the next version's 2.0, but I hadn't
  | heard we were following it with 3.0... ??

It was an idea floated around a while ago.
If you like, s/2.1/2.0.1/ and s/3.0/2.1/ in the proposal, to not get stuck
on the "what to call the next + 1 release" part of the idea :)


  | Modulo "_ALPHA" and 3.0 vs 2.1, I agree what you describe is probably the
  | clearest thing to do.

Ok, I take the point about "_ALPHA" and "/alpha" raised by Ben Harris
(and I don't know why I forgot about that, since I was one of the
releng pushing for removing "_ALPHA" in the release cycle naming :);
how about:
	3.0_CURRENT1
then?  (or "2.1_CURRENT1")

Luke.