Posted Sep 4, 2008 17:02 UTC (Thu) by iabervon (subscriber, #722)
Parent article: Linux 3.0?
I think spending 3 months removing things is a bit excessive. I'd say Linus should queue up a set of deprecated code removal patches in a branch, and, when he releases 2.6.30 (or something), merge that branch and release 3.0 fifteen seconds later. This has the big advantage that there's no non-deprecated difference between 2.6.30 and 3.0; so there's no migration pain going from 2.6.30 to 3.0 (aside from the fact that you'll have to have made sure that 2.6.30 isn't giving you any deprecation complaints), and people who have to roll back to 2.6.x because of finding that they're still using a deprecated feature don't have problems going back.
Then there would be a release cycle in which nothing could depend extensively on the deprecated stuff being gone (because there's zero time to write such a change between the 2.6.30 release and the 3.0.1 merge window), meaning that it would be 3.0.2 which people who needed the deprecated stuff really couldn't use (since it would be what includes the "now that that junk is gone, we can clean this code up and move forward" patches). In the 3.0.1 merge window, there would probably be a lot of dropping the parts of patches/merges that fix removed code for API changes (since -next wouldn't account for the removal), but that's easy enough.
Queuing up the actual removal commits for a just-removal release also means that they can be carefully vetted for only removing things that are producing loud warnings already and where exactly what will be removed has been publicized in patch-level detail.