[PATCH-NEW] README - Explain new 2.6.xx.x bug-fix release numbering scheme

[Daniel Andersen <anddan@linux-user.net>]

Forget the old patch.

Updated the patch to include examples and added a notification about the 
possibility that a bug-fix release of an older kernel could be released 
after a new x.y.Z has been released.

Feel free to comment and suggest changes to it, the whole point is to 
make it readable in a way that normal human beings can make some sense 
out of it. (Read: Your grandmother)

Daniel Andersen
--

diff -urN linux/README.orig linux/README
--- linux/README.orig	2004-08-14 07:37:40.000000000 +0200
+++ linux/README	2004-08-27 17:16:55.107413637 +0200
@@ -76,6 +76,23 @@
     the backup files (xxx~ or xxx.orig), and make sure that there are no
     failed patches (xxx# or xxx.rej). If there are, either you or me has
     made a mistake.
+
+   As of kernel 2.6.8 there was a bug-fix release numbering scheme
+   introduced. In such cases a fourth number is added to the release
+   version, eg. 2.6.8.1. When patching from a 2.6.xx(.x) release to a
+   newer version, patches are to be applied against the original
+   release, eg. 2.6.8 and not the bug-fix release 2.6.8.1. In case of a
+   bug-fix release such as if eg. 2.6.8.2 is released after 2.6.9 has
+   been released, 2.6.9 is still to be considered the newest kernel
+   release of all current kernels. Old patches can be reversed by
+   adding the "-R" option to the patch tool.
+
+                Example to apply a bugfix release patch:
+                bzip2 -dc ../patch-2.6.8.1.bz2 | patch -p1
+
+                Example to apply a new release on a bugfix tree:
+                bzip2 -dc ../patch-2.6.8.1.bz2 | patch -p1 -R
+                bzip2 -dc ../patch-2.6.9.bz2 | patch -p1

     Alternatively, the script patch-kernel can be used to automate this
     process.  It determines the current kernel version and applies any