[PATCH] Linux 3.8-merge version information

[PATCH] Linux 3.8-merge version information

[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 'merge' version information helps to not interfere with 3.7-stable git
versions in the bootloader (grub) selection until 3.8-rc1 is tagged.

Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>

---

diff --git a/Makefile b/Makefile
index 540f7b2..1fd4bf4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 3
-PATCHLEVEL = 7
+PATCHLEVEL = 8
 SUBLEVEL = 0
-EXTRAVERSION =
+EXTRAVERSION = -merge
 NAME = Terrified Chipmunk

 # *DOCUMENTATION*

Re: [PATCH] Linux 3.8-merge version information

[Linus Torvalds]

On Tue, Dec 11, 2012 at 5:06 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> 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

Re: [PATCH] Linux 3.8-merge version information

[Oliver Hartkopp]

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


On 11.12.2012 19:57, Linus Torvalds wrote:

> On Tue, Dec 11, 2012 at 5:06 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> 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

Re: [PATCH] Linux 3.8-merge version information

[Pavel Machek]

Hi!

On Tue 2012-12-11 10:57:21, Linus Torvalds wrote:
> On Tue, Dec 11, 2012 at 5:06 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> > 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.

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

No, it does not solve bisect, but at least you get something
reasonable in the boot menu...?

> 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

Problem is that CONFIG_LOCALVERSION_AUTO adds a lot of time to
build. Like... making "empty" build twice as slow.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html