I decided to write the following proposal after getting a headache trying to explain the Linux versioning scheme to a friend of mine. Only then did I find that the powers that be are talking about the same thing. It's far from a complete âengineering standardâ but it makes sense to me.
Disclaimers: INAKD (I am not a kernel developer) and IANASA (I am not a systems analyst) <major>.<minor>.<patch>.<bugfix> <major> is incremented when user-space ABI is broken. <minor> is incremented when there has been a big change/rewrite to one of the primary subsystems this would include times when for example the default scheduler was changed or the memory management algorithms were modifed. <patch> is incremented when a smaller change has been made to one of the primary subsystems, module has been added or depreciated. Modules should only be depreciated not be removed from the tree entirely during a <patch> release removal should be reserved for <minor> releases. Although it may be tempting to roll fixes that haven't yet been released in <bugfix> releases this should be avoided. <bugfix> is used and incremented as needed when fixing security vulnerabilities and bugs that cause systems to oops, panic and other nasty behavior. Features and speedups should never added in a bugfix release. Andrew's -mm tree would still exist though I think it would make sense if it were renamed to something like -dev or -exp (exp being short for experimental) to better convey the purpose of the tree to newbie kernel hackers and PHBs alike. The policy for this tree would be much more flexible as a development environment is required to be. With a designated development tree and more frequent <minor> release the odd/even minors could be done away with. Kernel developers, power users and other such folk should be encouraged to run the latest -dev/-exp releases where possible to test out current development directions. Although I have no experience with BK it seems to me that the it should be possible to implement a work flow as described above in any SCM. --adam - 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/
