[INFO] Kernel strict versioning

[Franco \"Sensei\"]

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@xxxxxx> <pgp:8998A2DB>
       <icqnum:241572242>
       <yahoo!:sensei_sen>
       <msn-id:sensei_sen@xxxxxxxxxxx>

Attachment: signature.asc
Description: OpenPGP digital signature