Glibc stable release process (Glibc 2.26.1)

[Romain Naour]

Hi All,

Le 16/10/2017 à 19:52, Jonathan Nieder a écrit :
> Hi,
> 
> Yann E. MORIN wrote:
> 
>> The problem is not about representation of the version string. It is
>> actually choosing what commit to use. As a downstream, we don't have
>> many options when we need to choose a commit on the maintenance branch
>> [1], i.e. either one of:
>>   - use the HEAD of the branch
>>   - use any one commit between the tag and the HEAD
>>
>> Let's say we choose HEAD now, and then tomorrow you push 5 new commits.
>> Then the HEAD we choose today will tomorrow be seen just as randomly
>> chosen as any other commit. It will tomorrow not mean much more than
>> if we had clicked on the "I feel lucky" button then.
> 
> I don't really follow.  Would the same problem exist when choosing
> between 2.26.1, 2.26.2, 2.26.3, etc?  Why isn't "use the latest
> version from the branch" always the right answer?
> 
>> As a consequence, it is very difficult to express what glibc version is
>> running on a system, because it would only ever report '2.26' (or am I
>> mislead?),
> 
> Are you talking about version numbers from the package manager or from
> somewhere else?

Here is the version reported by the libc on an embedded Linux system (i.e not a
Linux distro) without any package manager:

# /lib/libc.so.6
GNU C Library (Buildroot) stable release version 2.26, by Roland McGrath et al.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.2.0.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

So without any help from the build system, we can't say what's the libc version.
This can be ether the official Glibc 2.26 release or the glibc-2.26-58-gf725563.

In the end, git describe is not enough. Making a stable release require updating
verison.h and create a git tag.

Note: See I'm using gcc 7.2.0, not gcc-7_1_0-release-372-g1bd23ca.

Best regards,
Romain

> 
> Thanks,
> Jonathan
>