Glibc stable release process (Glibc 2.26.1)

Florian Weimer fweimer@redhat.com
Sat Sep 30 15:15:00 GMT 2017


On 09/30/2017 04:27 PM, Arjan van de Ven wrote:
> It also leads to, say, a CVE be able to list "fixed in 2.26.5"
> and everyone (and all more importantly, all tools that we all use
> to cross reference our distros to CVE databases) will know if things
> are already fixed, or if someone needs to take a look for a fix
> to backport outside of the releases

There aren't supposed to be any merges on release branches, and we 
should enforce that with an update hook (we currently don't).

If we do that and tag the master branch right after it is opened for 
development, then you could use “git describe” to generate unique 
version numbers for every commit on a stable branch.

Publishing tarballs just to turn 2.26-40 into 2.26.5 is a waste of 
resources, in my opinion.

Thanks,
Florian



More information about the Libc-alpha mailing list