All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH-NEW] README - Explain new 2.6.xx.x bug-fix release numbering scheme
@ 2004-08-27 15:27 Daniel Andersen
  2004-08-27 16:14 ` Chris Friesen
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Andersen @ 2004-08-27 15:27 UTC (permalink / raw)
  To: linux kernel mailing list

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH-NEW] README - Explain new 2.6.xx.x bug-fix release numbering scheme
  2004-08-27 15:27 [PATCH-NEW] README - Explain new 2.6.xx.x bug-fix release numbering scheme Daniel Andersen
@ 2004-08-27 16:14 ` Chris Friesen
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Friesen @ 2004-08-27 16:14 UTC (permalink / raw)
  To: Daniel Andersen; +Cc: linux kernel mailing list

Daniel Andersen wrote:

> 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)

> +   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. 

Perhaps "When patching from 2.6.x.y to 2.6.x.(y+1), patches are to be applied 
against 2.6.x, not 2.6.x.y."

Chris

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-08-27 16:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-27 15:27 [PATCH-NEW] README - Explain new 2.6.xx.x bug-fix release numbering scheme Daniel Andersen
2004-08-27 16:14 ` Chris Friesen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.