[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFD: Kernel release numbering
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 type of release ?
akpm: But that _is_ a branch

I think we all like the 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.512 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site