Re: RFD: Kernel release numbering

[Adam]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/