Re: [RFC] Kernel version numbering scheme change

Felipe Balbi
2008-10-20T20:56:46Z

On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > IMHO, having a small number of small digits is the way to go. Using
> > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
> > go to version 4.0. Anyway, there are so many changes between versions
> > these days that any new versions could justify a major change (eg:
> > check the size of the 2.6.27 patch).
> >
> > With versions from 1.1 to 9.9, you can go as high as 88 versions,
> > which is about 22 years of development at current pace. After that,
> > we can simply turn to 10.0 and not break anything.
> >
> > It's also easier for users. Check how many non-kernel techies around you
> > know all 3 digits of the version they use. It's easier to remember 4.3
> > than it is to remember 2.6.27.
>
> I agree that would be nicer, and easier for everyone.

It's true it would be easier for tracking down and remembering the
version number, but on the other hand, the good thing about this
version number system is that we now 2.6.xx is a rather stable and
complete kernel tree and when we move to 2.7, we know it'll be the start
for the 2.8 kernel series.

Just like the migration from 2.4 to 2.5.

Also, changing now the version numbering would be troublesome as well.
Most of the users/developers who tracks linux-2.6.git are used to
have 3 levels of version number.

Still, it's nice to start thinking about it now since we're getting
closer to last sublevel of 2.4 series (i think it was 2.4.37 ??) and try
to find a new scheme for version numbering before thinking about 2.7 (or
3.0 ??) series.

--
balbi