RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Sep 5, 2008 15:13 UTC (Fri) by iabervon (subscriber, #722)
In reply to: RFC: adding a 'version' flag process to kernel development in a non-destructive manner by kirkengaard
Parent article: Linux 3.0?

I assume that the stable team would maintain the last 2.6.x.y in parallel with 3.0.0.y (particularly if they're identical aside from 3.0.0.y having chunks removed), and drop it along with 3.0.0.y around when there are no known regressions left in 3.0.1.y.

It should be relatively easy to minimize the stuff that requires 2.6, because the criteria for deprecating something is that either it doesn't exist any more (so far as anybody can tell) or it has a working replacement. If anyone actually can't switch from 2.6 to 3.0, then something from 2.6 needs to be brought back. This is different from 2.4->2.6, where there were a number of things that had to be done in combination with the transition because neither 2.4 nor 2.6 was a superset of the other. If 3.0 is exclusively a feature-removal release, then it's a proper subset of the last 2.6, and if you can get to the last 2.6 and have your system work, and you run without getting deprecation warnings, then you can move to 3.0 without any more changes.

to post comments

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Sep 5, 2008 21:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Yeah, but some of the comments in this thread have been talking about
dropping old syscalls and breaking userspace compatibility. Personally I
don't think anyone would care if, say, a.out and all syscalls obsoleted
before the ELF transition stopped working (it happens regularly already
for many kernel releases at a time: Alan Cox was the last person I've
heard of who runs stuff on libc2 and libc3, and even he's stopped now),
but breaking anything from the ELF era is probably a mistake.

RFC: adding a 'version' flag process to kernel development in a non-destructive manner

Posted Jul 2, 2009 18:48 UTC (Thu) by duncan1 (guest, #59412) [Link]

3.0 is exclusively a feature-removal release,
I don't think so. If they are worried about obsolescence or bloat, then they should set a ratio of adding new features to removing obsolete features. Then change the ratio as necessary.