Glibc stable release process (Glibc 2.26.1)

[Paul Eggert]

Romain Naour wrote:
> Maybe a middle ground is that a tag is pushed to the repository, just to
> identify a specific sha1 as "this is 2.26.1". This is relatively lightweight (a
> signed tag) and gives downstream users that need it a clear identification of a
> blessed version.
That "blessing" would be problematic. How can we be expected to "bless" any 
particular commit unless we've checked it? And that checking will take some 
work, work that will slow us down on other things.

Instead of blessing, how about using the output of something like the following 
shell command to generate the version number?

git describe --match 'glibc-*' --abbrev=7 --dirty

This will generate a string that identifies the commit but is shorter and easier 
to read than an SHA hash, and so is more likely to give users that warm and 
fuzzy feeling. On my glibc repository right now, for example, it generates:

glibc-2.26-415-g4d3693e

which means there have been 415 commits since 2.26, and the latest commit can be 
abbreviated 4d3693e. A similar (but shorter) version-numbering scheme is used by 
GNU Coreutils and other GNU packages when between releases, and Gnulib has a 
script build-aux/git-version-gen that can generate it.