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.
