Re: Updating release version to 22.1

[Miles Bader]

On Wed, 09 Feb 2005 09:30:42 +0100, Kim F. Storm <address@hidden> wrote:
> Miles Bader <address@hidden> writes:
> 
> > On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm <address@hidden> wrote:
> >> > On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <address@hidden> wrote:
> >> >> What's the rational for not using 22.0.x for development versions?
> >> >> It would be so much simpler ...
> >>
> >> Because it - IMO - is confusing.
> >
> > What, compared to all the other bizarro schemes being suggested here
> > ("hey I know, let's make pre-releases _blue_, and real releases
> > _green_!")?  You've got to be kidding... please say you're kidding...
> 
> Not really!
> 
> The problem with our _current_ scheme is that even though we seem to want to
> postpone the decision about exactly what number the next release gets, it
> is recorded _NUMEROUS_ places all over the sources and other files
> (in total, I had to change 21.4 to 22.1 in more than 500 places).
> 
> I don't want us to get into that mess again -- so I want a scheme
> where the next release number is _fixed_ from the start.

I have no idea what you're talking about.

The problems caused by the current "mess" (21.4 released to mean
something else, 22.1 chosen for next release) would have happened
regardless of what scheme was chosen (including all of your wacky
ones), because what occured is that an extra real release was added in
between the last real release and the designated next real release. 
No amount of futzing around with pre-release names would have changed
that.

The questions, as I understand it, are merely (1) how to call real
releases, and (2) how to call pre-releases.

For the next release at least, it's been decided that (1) will be
"22.1"; what I understand Jérôme to have meant is that (2) in this
case should be "22.0.x", where x = 1, 2, 3, ...

-Miles
-- 
Do not taunt Happy Fun Ball.