Re: RFD: Kernel release numbering

Andries Brouwer
2005-03-03T14:59:22Z

Ha - a nice big thread. Issues include trivial fixes, testing,
and API stability.

-----
About trivial fixes:
davem: the day Linus releases we always get a pile of "missing MODULE_EXPORT()"
type bug reports that are one liner fixes.
davej: So what was broken with the 2.6.8.1 type of release ?
akpm: But that _is_ a branch

I think we all like the 2.6.8.1 model.

davej: The only question in my mind is 'how critical does a bug have to be
to justify a .y release'.

I think that is the wrong question. The question should be 'how trivial
should a fix be to be admissible in a .y release'. If something is important
but nonobvious, it should cause earlier release of 2.6.x+1.
No regressions in 2.6.x.y.

-----
About testing: users do not test p.q.r-suffix, they just test p.q.r
Solution: Release early, release often. No silly odd/even games.
jgarzik: I would prefer a weekly snapshot as the release

-----
API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
the guarantee that user-visible APIs do not change. That goal
has disappeared, meaning that anything might break when one
upgrades from 2.6.14 to 2.6.16.
This is one of the big disadvantages of the new 2.6 way.

-----
A separate twig is that of when to call a release 'stable'.
Since there is no good way to predict, the solution is 'wait and see'.
'Stable' also depends on the type of use. It is easier to leave
construction of stable kernels to separate people and trees.
With some delay they can have the benefit of hindsight.

Andries