Re: RFD: Kernel release numbering

Ryan Anderson
2005-03-03T03:54:05Z

On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> The problem with major development trees like 2.4.x vs 2.5.x was that the
> release cycles were too long, and that people hated the back- and
> forward-porting. That said, it did serve a purpose - people kind of knew
> where they stood, even though we always ended up having to have big
> changes in the stable tree too, just to keep up with a changing landscape.

How about this idea, instead:

At 2.6.12, make two parallel BitKeeper trees:

2.6 and 2.7

Push bugfixes into 2.6.

Push *everything* that's not a bugfix into 2.7.
"bk pull" the 2.6 tree into the 2.7 tree each day when you wake up.

A week later, release 2.6.12.1 from the 2.6 tree, then immediately bk
pull the 2.7 tree into the 2.6 tree.

Release 2.6.13-rc1 at about the same time, and again only take bugfixes
into the 2.6 tree.

In 3-7 weeks, after a few more -rc iterations with just bugfixes,
release 2.6.13.

This should keep the differences between the trees down to something
somewhat... sane, and, hopefully, keep the stable tree stable.

People working on big changes can do them against 2.6.x if they need
stability, and know that if they stay current with each 2.6.x release as
they work, they should have a controllable amount of pain for merges.

My thinking is simply that if you're going to use BitKeeper, you might
as well abuse it for all that it's worth.

--

Ryan Anderson
sometimes Pug Majere