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

---

gnu/packages/golang.scm | 44 +++++++++++++++++++----------------------

1 file changed, 20 insertions(+), 24 deletions(-)

merge 60898 60899 60900 60901 60902

merge 60898 60903 60904 60905 60906

merge 60898 60907 60908 60909 60910

merge 60898 60911 60912 60913 60914

merge 60898 60915 60916 60917 60918

merge 60898 60919 60920

merge 60898 60921 60922

thanks

Weird: I got ‘Unknown command or malformed arguments to command.’ for

this obviously correct line.

Let's try again.

merge 60899 60904 60907 60908 60917 60920 60921 60919 60910 60903 60915 60914 60922 60909 60918 60913 60900 60899 60905 60901 60912 60898 60906 60902 60916 60911

--

Katherine

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

I'm not sure I prefer the longer version here, and also having the

commit in the origin but then part of it in the version makes this a

little harder to update since you have to update both bits.

What led you to change from using the (let ((... bit here?

As Chris said, don't use this kind of version string :)

And especially don't write the commit twice.

(synopsis "Generate and print diffs in Go")

(description

"This package provides a Go library to generate and print file

differences in the @code{diff} format.")

-- (

"( via Guix-patches" via <guix-patches@gnu.org> writes:

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 only bumped the version here; the synopsis was pre-existing. But: is the language important? Do we say "Diff creates and prints diffs in

C"?

[1] https://go.dev/doc/modules/version-numbers#in-development

--

Katherine

On Tue Feb 7, 2023 at 5:04 PM GMT, Katherine Cox-Buday wrote:

Hmm, interesting. I think this would be better answered by more experienced

contributors.

I should've elaborated: use GO-VERSION->GIT-REF here :)

Isn't this also a Go library? If it isn't, then yeah, it's not important,

but if it is, I'd say you should add "in Go".

-- (

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

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.