On Sat, 28 Apr 2007, Bryan WU wrote:
>
> You know, because the kernel development is so active and so many stable
> versions release, it is very hard to decide use which version for mass
> production, especially some embedded systems which does not often
> upgrade.
I actually think that one of the advantages (at least that was the _plan_)
of having kernel releases every two-to-three months is that for vendors
who don't upgrade very often, you should always have a choice of few
kernels to decide on - you can simply decide to go with a less recent
kernel that you've been testing for a while.
And with a fairly short release cycle, even if you decide that "hey, we
just don't know enough about the latest kernel, so let's go with the <n-1>
release", you won't be _totally_ behind the times. Yeah, you'll be using
something older, but it will be just two months older, not "totally
ancient".
In other words, the fact that the kernel developers cut releases fairly
often should mean that vendors can much more easily decide on their own
release cycle _independently_ of the kernel release cycle, because at any
point in time, you always have *some* kernel release that isn't horribly
old, and that you can have a few months of knowledge about.
Compare that to a release cycle of every two years or something (eg a
major gcc release), where if you're unlucky, you have the choice between
"recent and all the features, but it's not seen a lot of testing yet", or
"really quite old and stable, and we'll look bad for packaging it when
people know there is a much more recent release".
In that kind of situation, a downstream vendor just doesn't have a lot of
good choices: delay the release until you know more about the package, or
ship a really old version, or ship a new and scary one. All three are "big
choices", and you can just pray you do the right one.
In contrast, the kernel release cycle has been geared to making those
choices "small and inconsequential". Right now, you can basically choose
between any of
- 2.6.19.7
- 2.6.20.10
- 2.6.21.1
and none of them are horribly old, and you can base your choice on just
how adventurous you are _and_ on being familiar with two of them.
For example, I think 2.6.20 was a good release, and so my gut feel is that
2.6.20.10 is probably preferable over the 2.6.19-based one, but if you
want to live on the edge, you'd pick 2.6.21.1, and if you want to go for
having a _loong_ time of being comfy with something, you might decide to
go with 2.6.16.49 that Adrian has been maintaining.
In other words, having tight development releases just makes all these
choices easier. There's more choice, for sure, and that could feel scary,
but at the same time, it should result in less of a "choice between two
evils" kind of situation, and more of a "I *can* make an informed choice
if I just spend some effort on it".
At least that was the plan. From everything I've heard, most people are
pretty happy with the 2.6.x development model. You cannot please
everybody, but the release frequency means that developers feel like they
can work on relevant stuff all the time, and vendors can always choose
something that is known stable and not horribly ancient.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
