Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes: > Simon Josefsson wrote: >> This also change from using 'git describe || git rev-parse --short=10' >> to using 'git rev-parse', which results in announcement to look like >> this: >> >> This release was bootstrapped with the following tools: >> Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 >> >> instead of >> >> This release was bootstrapped with the following tools: >> Gnulib v1.0-1286-g552c0b0635 >> >> and while I would agree that the full SHA1 isn't the prettiest ... > > In an earlier discussion, I mentioned that for the purpose of the > reproducible tarballs, the meta-information about the used Gnulib > and Autotools versions should be in a machine-readable file, *not* > in a release announcement (since the latter is distributed in mailing > lists). > > But if you put information into release announcements, it would be > good to make an effort to make it meaningful for a human reader. > > A line > Gnulib v1.0-1286-g552c0b0635 > was meant to be useful for a human, but never was, since Gnulib > has no release tags other than v0.1 and v1.0. > > A line > Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 > is completely useless for a human. > > What a human reader would like to understand is whether such a > commit number is recent or not. Therefore, what I would suggest > is to suffix it with a date: > > Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 (2024-12-28)
I agree. Even the date is more human friendly, so how about Gnulib 2024-12-28 (552c0b06355a6720c8ce87ce305f42ed15a32d20) ? The TZ question arise here again (git commit timestamp vs TZ-less ChangeLog date), but let's hope it won't be a big problem in practice. /Simon
signature.asc
Description: PGP signature
