[bug#60905] [PATCH 08/25] gnu: go-github-com-pkg-diff: Update to 0.0.0-20210226163009-20ebb0f2a09e.

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]


Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> "( via Guix-patches" via <guix-patches@gnu.org> writes:
>
>> * gnu/packages/golang.scm (go-github-com-pkg-diff): Update to
>> 0.0.0-20210226163009-20ebb0f2a09e.
>>
>>> --- a/gnu/packages/golang.scm
>>> +++ b/gnu/packages/golang.scm
>>
>>> @@ -8736,30 +8736,26 @@ (define-public go-github-com-go-git-go-git-fixtures
>>
>>> +  (package
>>> +    (name "go-github-com-pkg-diff")
>>> +    (version "0.0.0-20210226163009-20ebb0f2a09e")
>>
>> As Chris said, don't use this kind of version string :)
>
> Ah, I actually have (what I think) is a valid reason for this. In Go,
> when a module is in development, this long string, including the SHA, is
> the actual version[1] of the module, and carries semantics for Go
> developers, i.e. "Signals that the module is still in development and
> unstable. The release carries no backwards compatibility or stability
> guarantees."
>
> It's how it will be referenced by other Go modules, and so I thought it
> best to make the version field reflect the actual version. The previous
> iteration of this package had an incorrect version: upstream did not
> assign it a 0.0.1 version; that's something we did.
>
> I agree that this is confusing for Guix maintainers, and causes
> duplicate information in the version and commit fields.
>
> What are your opinions on this?

I guess I'm not that fussed if a long version has some use.

What I would say is that as long as the version incorporates the commit
in some way and the commit is used in the package source bit, I'd use
the (let ((commit ... pattern to avoid duplicating bits of the commit
hash and make tweaking the commit easier.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]