Re: RFD: Kernel release numbering

[Thomas Graf]

* David S. Miller 2005-03-02 20:05
> On Wed, 02 Mar 2005 21:32:23 -0500
> Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
> 
> > I also note that part of the problem that motivates the even/odd thing 
> > is a tacit acknowledgement that people only _really_ test the official 
> > releases.
> > 
> > Which IMHO backs up my opinion that we simply need more frequent releases.
> 
> This more frequent release idea will basically mimmick what the
> even/odd idea will do, except that even/odd will have specific
> engineering goals.  Development vs. pure bug fixing.

Agreed, more frequent releases, even/odd, and 2.6.x.y all get down to
the same idea being making it easier for the end-user to test it and
thus achieving releases with less regressions.

I don't see any difference between 2.6.x.y and even/odd regarding
the process just after a stable release. The 2.6.x.y clearly has
the advantage that all those small nasty bugfixes such as missing
exports, typos and all the other one-liners can be brought to the end
user more easly in the middle of a development cycle. The even/odd
idea cleary has the advantage of a clear statement regarding what will
be the final release candidate. So let's combine both ideas and
get the advantages of both.

I think it is completely unimportant how to call it, be it .odd,
.even-test, .even-final-rc, 2.6.x.0 or whathever. The most important
part is to communicate this to the end-user. A well formed release
diagram on kernel.org would do just fine.

Basically it gets down to this:

 + > start of development cycle
 |            |<--+
 |            v   |
 |           rcX -+
 |            |
 |            v
 |         final rc
 |            | (Only fixes here)
 |            v
 +----- stable release -----> fixes branch---+
                         ^                   |
                         +-------------------+

It's already like this right now except that the final rc isn't
marked as such and a branch for stable release fixes (including
only the very imporant fixes) is missing.  The situation for the
maintainers wouldn't change a bit.

Applied to combined even/odd and 2.6.x.y it would be:

    2.6.12 -> 2.6.13-rcX -> 2.6.13 -> 2.6.14 -> 2.6.15-rcX
                                        |
                                        v
                                     2.6.14.y

My personal preference would be to suffix the final odd release with
-test just to more clearly mark it but that's a very minor cosmetic thing.

I'm not sure wehther the test release thing will increase the number
of testers but it's sure worth a try. A real advantage would be that
everyone interested in a smooth migration to the next stable release
can give the test release a try and will see eventual regressions
fixed before the final stable release with a very low risk of new
regressions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/