This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Glibc stable release process (Glibc 2.26.1)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]