Re: Can we find a better idiom for unversioned packages?

["Leo Famulari" <leo@famulari.name>]

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.

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.

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.

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