Re: RFD: Kernel release numbering

[Barry K. Nathan]

On Wed, Mar 02, 2005 at 07:37:44PM -0800, Linus Torvalds wrote:
> On Wed, 2 Mar 2005, Jeff Garzik wrote:
[snip]
> > 2.6.x-pre: bugfixes and features
> > 2.6.x-rc: bugfixes only
> 
> And the reason it does _not_ work is that all the people we want testing 
> sure as _hell_ won't be testing -rc versions.

Maybe that's because you redefined "rc" to mean "ridiculous count"?
People would rather test a release candidate than a ridiculous count. ;)

> That's the whole point here, at least to me. I want to have people test 
> things out, but it doesn't matter how many -rc kernels I'd do, it just 
> won't happen. It's not a "real release".
> 
> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

Am I the only person here who doesn't see it as "either/or"? ISTM that
"odd/even" and the "2.4 approach" are orthogonal issues.

What about something like the following? (It probably needs tweaks but
it might be worth considering.)

2.6.odd-alpha1: Equivalent to 2.6.x-rc1.
...
2.6.odd-alphaA: Equivalent to 2.6.x-rcA. (A is a constant. Linus gets to
                set it, perhaps before relesing alpha1. Perhaps A=1 or
                A=2 could be tried for the 2.6.13 cycle. Setting it to
                an arbitrary value should free Linus's brain for other
                matters.)
2.6.odd-beta1:  Equivalent to 2.6.x-rc(A+1).
...
2.6.odd-betaX:  Equivalent to the last 2.6.x-rc in the current scheme.
2.6.odd-rc1:    Equivalent to 2.6.x *RELEASE* now.
...
2.6.odd:        *Identical* to last 2.6.odd-rc. Not a single patch of
                difference, except for the version number! If you
                committed anything since 2.6.odd-rcX, then either (a)
                you need to make a 2.6.odd-rc(X+1), or (b) you committed
                something that should have waited for the next 2.6.odd.
2.6.even-beta1: Skipping -alpha because we're only going for bugfixes
                in even, right? (*Please* listen to davej and don't
                treat drivers differently than core code. If you must
                include major driver updates, then don't skip -alpha.)
...
2.6.even-rc1:   This is when you think you're completely done with
                2.6.even and you think it's time to upload the final
                release.
...
2.6.even:       This is the last 2.6.even-rc, with no changes. (Same -rc
                rules as for 2.6.odd-rc.)
(...cycle repeats...)

For an approximation of the so-called "2.4 approach", let A=0 and
s/beta/pre/g. Perhaps the alpha/beta distinction won't *really* mean
anything, but it might have a subliminal effect on everyone. :) Anyway,
if the alpha/beta distinction is overengineering, it's easily removed
(see the beginning of this paragraph).

Whether with alpha/beta or just plain pre, this seems more robust to me
than the other suggestions so far.

-Barry K. Nathan <barryn@xxxxxxxxx>
-
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/