[INFO] Kernel strict versioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:[email protected]> <pgp:8998A2DB>
       <icqnum:241572242>
       <yahoo!:sensei_sen>
       <msn-id:[email protected]>

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux