README (resend) - Explain new 2.6.xx.x version number
PATCH 1/1 README (resend) - Explain new 2.6.xx.x version number
This one ended up in the void last time without any comments.
Daniel Andersen
--
README 2004-08-27 17:16:55.107413637 +0200 renamed from README.orig 2004-08-14 07:37:40.000000000 +0200 +17 -0
@@ -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
README 2004-08-27 17:16:55.107413637 +0200
Quoted 4 lines · Daniel Andersen
README 2004-08-27 17:16:55.107413637 +0200 renamed from README.orig 2004-08-14 07:37:40.000000000 +0200 +4
-0+ 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.
This bit seems odd to me. Why would a 2.6.8.2 get released, when there's a newer 2.6.9 which should fix whatever was relevant to get into 2.6.8.x ?
Dave
Quoted 7 lines · Dave Jones
README 2004-08-27 17:16:55.107413637 +0200
Quoted 4 lines · Daniel Andersen
README 2004-08-27 17:16:55.107413637 +0200 renamed from README.orig 2004-08-14 07:37:40.000000000 +0200 +4
-0+ 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.
Quoted 5 lines
This bit seems odd to me. Why would a 2.6.8.2 get released, when there's a newer 2.6.9 which should fix whatever was relevant to get into 2.6.8.x ?
Dave
This was discussed in the thread "Linux 2.6.9-rc1". Linus said there was a remote possibility it could happen some day so I thought it was a good thing to mention.
Daniel Andersen
--
Hi,
Quoted 1 line · Daniel Andersen
This one ended up in the void last time without any comments.
The funny thing is by the time people managed to apply the patch correctly, they don't need to read the README anymore. Seriously, without knowing about the pre-patches, what would you expect about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9?
bye, Roman
Quoted 5 lines · Roman Zippel
Hi,
On Tue, 14 Sep 2004, Daniel Andersen wrote:
Quoted 7 lines
Quoted 1 line
This one ended up in the void last time without any comments.
The funny thing is by the time people managed to apply the patch correctly, they don't need to read the README anymore. Seriously, without knowing about the pre-patches, what would you expect about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9?
bye, Roman
I'm not sure what you really mean to say. And I'm not expecting anything. I wrote the patch because I see people ask, even on this list, if 2.6.9 is to be applied against 2.6.8 or 2.6.8.1. Whats the trouble?
Daniel Andersen
--
Quoted 8 lines
Hi,
Quoted 1 line · Daniel Andersen
This one ended up in the void last time without any comments.
The funny thing is by the time people managed to apply the patch correctly, they don't need to read the README anymore.
That's correct for this time. However, if they have other kernel trees (in the future) with this patch applied, it can help.
Quoted 2 lines
Seriously, without knowing about the pre-patches, what would you expect about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9?
We have evidence that it's confusing to more than one person.
~Randy
Quoted 8 lines · Randy.Dunlap
Quoted 7 lines
Hi,
Quoted 1 line · Daniel Andersen
This one ended up in the void last time without any comments.
The funny thing is by the time people managed to apply the patch correctly, they don't need to read the README anymore.
Quoted 7 lines
That's correct for this time. However, if they have other kernel trees (in the future) with this patch applied, it can help.
Quoted 2 lines
Seriously, without knowing about the pre-patches, what would you expect about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9?
We have evidence that it's confusing to more than one person.
Using 2.6.8-fix1 instead of 2.6.8.1 could avoid such problems. --
vda
Hi,
Quoted 4 lines · Randy.Dunlap
Quoted 2 lines
Seriously, without knowing about the pre-patches, what would you expect about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9?
We have evidence that it's confusing to more than one person.
The question is what is more confusing to most of the users? What are the expectation of the average user?
bye, Roman
On Wed, 15 Sep 2004 13:06:06 +0200 (CEST) Roman Zippel wrote:
| Hi, | | On Tue, 14 Sep 2004, Randy.Dunlap wrote: | | > > Seriously, without knowing about the pre-patches, what would you expect | > > about the patch order if you found the patches 2.6.8, 2.6.8.1, 2.6.9? | > | > We have evidence that it's confusing to more than one person. | | The question is what is more confusing to most of the users? | What are the expectation of the average user?
I have no idea. A decision was made and now there are some attempts to document it. Are you trying to ask for the decision to be reconsidered?
--
~Randy
Hi,
Quoted 2 lines · Randy.Dunlap
I have no idea. A decision was made and now there are some attempts to document it.
When and by whom?
Quoted 2 lines
Are you trying to ask for the decision
to be reconsidered?
I'd really be interested in the reasoning for it and against the alternatives.
bye, Roman