lkml.org 
[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[INFO] Kernel strict versioning
Hi. I'm new in the list... please excuse me, I'm probably naive.

I'm using linux from 1997, and now I'm wondering why the kernel
versioning system has been so strict. I've been following the thread
``RFD: Kernel release numbering'', but still I have some concerns...

Earlier versions used the odd/even numbering, unstable/stable
versioning. That was quite good from a user's point of view, since it
carried significant meaning immediately.

The fact that we face a multilevel versioning number, say
2.6.11-14.4.whatever-2 is quite a pain. I'm saying not that it's a bad
idea that a product has more versions, my product follow the even/odd
and subversion numbering. I'm saying that the scripts used in the kernel
building should be quite smarter.

Actually changing a kernel results in creating a /lib/modules/version
directory, creating a heavy confusion for a user, especially when
compiling other modules outside the official kernel release: he juts
looses the modules and has to recompile them.

I was wondering about the feasibility of handling just a MAJOR.MINOR
versioning. This would be quite an increment for a user to mantain his
kernel. Modules can still be loaded and found. We would have a single
/lib/modules/2.6 being much compatible with other modules, working with
2.6.x and 2.6.y without any difficulty. Also the source tree from a
user's point of view is much cleaner, identifying the ongoing kernel
much easily.

I'm not talking about the developing process, which still uses 2.6.x,
and it's good as it identifies the current subversion, but there's no
use in collecting so many other kernels when considering them ``stable''.

I'm just wondering...

--
Sensei <mailto:senseiwa@tin.it> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:sensei_sen@hotmail.com>
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-04-08 20:13    [from the cache]
©2003-2011 Jasper Spaans