[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Xinglu Chen |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Wed, 01 Sep 2021 18:50:36 +0200 |
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. :-)
signature.asc
Description: PGP signature
- 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/01
- Re: Can we find a better idiom for unversioned packages?,
Xinglu Chen <=
- 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