Linux 3.8-merge version information
PATCH 1/1 Linux 3.8-merge version information
As the automatically generated git version information is misleading in the merge window, name the kernel in the merge window as 3.8-merge .
This 'merge' version information helps to not interfere with 3.7-stable git versions in the bootloader (grub) selection until 3.8-rc1 is tagged.
---
Makefile +2 -2
@@ -1,7 +1,7 @@ VERSION = 3 -PATCHLEVEL = 7 +PATCHLEVEL = 8 SUBLEVEL = 0 -EXTRAVERSION = +EXTRAVERSION = -merge NAME = Terrified Chipmunk # *DOCUMENTATION*
Quoted 2 lines · Oliver Hartkopp
As the automatically generated git version information is misleading in the merge window, name the kernel in the merge window as 3.8-merge .
This really doesn't help.
90% of the commits during the merge window wouldn't be based on that Makefile change anyway, but on some much older version. So when bisecting, for example, you'll see Makefiles with much older version numbers, even though the commits got merged into the 3.8 merge window.
Also, we have code to generate the version number automatically. In particular, I encourage people to use git trees and CONFIG_LOCALVERSION_AUTO=y, because then your /var/log/messages (and uname -r) will contain the exact git version of your kernel. So when you see something like
Linux version 3.7.0-rc8-00041-gcaf491916b1c
in your message log, you'll know that the kernel you were running back then was 41 commits past -rc8, and had git commit ID of caf491916b1c. And that is really useful for things like bisections ("Ok, I know it worked three days ago - what kernel was I running then?") much more so than a Makefile change would be (never mind how unreliable the version info in the makefile is).
So this is why we only change the version in the Makefile when we do a new tagged release.
Linus
Thanks for your explanation.
Indeed i was not really aware of commit counter as the first number, even if i used CONFIG_LOCALVERSION_AUTO=y for a while now.
The obviously outdated Kconfig help of CONFIG_LOCALVERSION_AUTO told me:
A string of the format -gxxxxxxxx will be added to the localversion if a git-based tree is found. The string generated by this will be appended after any matching localversion* files, and after the value set in CONFIG_LOCALVERSION.
(The actual string used here is the first eight characters produced by running the command:
$ git rev-parse --verify HEAD
which is done within the script "scripts/setlocalversion".)
Maybe you can integrate parts of your comprehensive answer into this help text, as it will fit better than my awkward English %-)
Tnx & best regards,
Oliver
Quoted 30 lines · Linus Torvalds
Quoted 2 lines · Oliver Hartkopp
As the automatically generated git version information is misleading in the merge window, name the kernel in the merge window as 3.8-merge .
This really doesn't help.
90% of the commits during the merge window wouldn't be based on that
Makefilechange anyway, but on some much older version. So when bisecting, for example, you'll see Makefiles with much older version numbers, even though the commits got merged into the 3.8 merge window.Also, we have code to generate the version number automatically. In particular, I encourage people to use git trees and
CONFIG_LOCALVERSION_AUTO=y, because then your/var/log/messages(and uname -r) will contain the exact git version of your kernel. So when you see something likeLinux version 3.7.0-rc8-00041-gcaf491916b1cin your message log, you'll know that the kernel you were running back then was 41 commits past -rc8, and had git commit ID of
caf491916b1c. And that is really useful for things like bisections ("Ok, I know it worked three days ago - what kernel was I running then?") much more so than aMakefilechange would be (never mind how unreliable the version info in the makefile is).So this is why we only change the version in the
Makefilewhen we do a new tagged release.Linus
Hi!
Quoted 5 lines · Linus Torvalds
Quoted 2 lines · Oliver Hartkopp
As the automatically generated git version information is misleading in the merge window, name the kernel in the merge window as 3.8-merge .
This really doesn't help.
Well, I'd say it helps in the common case.
Quoted 5 lines
90% of the commits during the merge window wouldn't be based on that
Makefilechange anyway, but on some much older version. So when bisecting, for example, you'll see Makefiles with much older version numbers, even though the commits got merged into the 3.8 merge window.
No, it does not solve bisect, but at least you get something reasonable in the boot menu...?
Quoted 7 lines
Also, we have code to generate the version number automatically. In particular, I encourage people to use git trees and
CONFIG_LOCALVERSION_AUTO=y, because then your/var/log/messages(and uname -r) will contain the exact git version of your kernel. So when you see something likeLinux version 3.7.0-rc8-00041-gcaf491916b1c
Problem is that CONFIG_LOCALVERSION_AUTO adds a lot of time to build. Like... making "empty" build twice as slow.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html