On Wed, Sep 01 2021, Leo Famulari wrote:

> On Wed, Sep 1, 2021, at 06:55, Xinglu Chen wrote:
>> I never felt like including the commit id in the version of a package
>> was useful; e.g., just seeing the first seven characters of the commit
>> id doesn’t really tell me anything about the version.  I think it is
>> more useful to put the date of the commit in the version; Nixpkgs does
>> something like this[1].  I have started to put the date of the commit in
>> a comment, just to make it easier for people to know how old it commit
>> is; otherwise, one would have to find the VCS repo and find the commit
>> just to see how old the commit is.
>
> The issue I see with only using the date is that Git dates are not
> unique, in order, or even meaningful in a clear way.

Well, seeing

  foo-1.0.0-1.2021-01-31

gives a user more useful information than something like

  foo-1.0.0-1.cabba9e

With the former, I can quickly see that the version is from 2021-01-31,
whereas with the latter, I would have to either find the VCS repo online
or go to my local checkout of it and browse the logs.

> Commit dates don't have a consistent meaning: are they the time of
> first revision of a commit? Final revision of a commit? Time of
> signing? Pushing? They are often useful to estimate a timeline, but
> it's common for a Git "timeline" to jump back and forth by months or a
> year due to long-running development branches being merged in, or due
> to a "commit and then polish by rebasing" workflow.

I would say the the time of the final commit would be the best option,
but I agree that it can be ambiguous.

> Using the revision ID (of sufficient length) gives an unambiguous
> reference to the upstream source of a package and its artifacts in the
> store. How would you describe a package version to upstream when
> reporting a bug, except by revision ID? You can't tell them a
> timestamp and expect them to know which code a buggy package is based
> on.

One can get the commit id of a package by simply running ‘guix edit
PACKAGE’ and copying the commit id from the package definition.  I don’t
think hiding the commit id from the package version would be a problem
for this situation.

> We could certainly add a timestamp to our version strings for
> VCS-based packages, but we should keep the revision ID too.

I haven’t really found the commit id that useful when looking at the
version of a package; adding a timestamp would certainly be better than
the status quo.  :-)