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