[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Leo Famulari |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Wed, 01 Sep 2021 11:37:13 -0400 |
User-agent: |
Cyrus-JMAP/3.5.0-alpha0-1126-g6962059b07-fm-20210901.001-g6962059b |
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.
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?,
Leo Famulari <=
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/04
- Re: Can we find a better idiom for unversioned packages?, Ludovic Courtès, 2021/09/08