Glibc stable release process (Glibc 2.26.1)
Jonathan Nieder
jrnieder@gmail.com
Mon Oct 16 17:52:00 GMT 2017
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?
Thanks,
Jonathan
More information about the Libc-alpha
mailing list