Hi Tomas,
Tomas Volf <[email protected]> writes:
Hi,
when I started up a shell with a go, I noticed that the version
I got
was a big weird, 1.26rc1 to be precise. According to Efraim
that is
fine, but I do not understand why (I am not disputing, just
looking to
understand). Should not the package one gets from
guix shell go
not be the latest, but *stable* version (so currently go-1.25)?
Especially since we are getting close to a release, it feels
weird to
have go default to a release candidate.
Guix has multiple versions of Go packaged:
$ guix show go | grep ^version
version: 1.26rc1
version: 1.25.5
version: 1.24.3
version: 1.23.9
version: 1.22.12
version: 1.21.13
version: 1.20.14
version: 1.17.13
version: 1.4-bootstrap-20171003
When you run `guix shell somepackage', you always get the latest
packaged version, which in this case, is 1.26rc1. If you want a
specific version, you can `guix shell [email protected]' (or whatever
version you want).
When building Guix packages, Go 1.24 is the default, as this is
what’s bound to the `go' symbol in (gnu packages golang).
I guess I have two questions:
1. Why not have go-next instead if 1.26 is needed for some
reason?
This is effectively what the Go 1.26rc1 package is. There appears
to be no consistency as to whether a foo-next variable refers to a
package with name "foo" or "foo-next" -- I see many examples of
both in the codebase.
2. What are rules for when it is fine to update package to
release
candidate instead of waiting for the final version?
I don’t believe Guix has any rules around this, but also, such
rules would not apply to this situation. It’s not a package
update in the strict sense of changing a "go" package from 1.25 to
1.26rc1. It’s the addition of a Go 1.26rc1 pacakge, while
retaining several earlier versions.
-- Ian
