Ian Eure <[email protected]> writes: > 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).
Of this I am aware and am following so far. > >> 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. That seems... sub-optimal. In my opinion asking for `go' and getting an unstable version is simply not great. Maybe we should be consistent and have the -next as a rule? Would this require a GCD? > >> 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. I find this a very pedantic point of view. While yes, on the level of variables you are correct, I would assume lot of people (me included) use `guix shell go' and similar. Heck, even the specifications->manifest seems preferred (both --export flag of shell, and in manual) to packages->manifest. Just to reiterate, I have no problem with a hypothetical change from go 1.25 to 1.26. That is expected (and actually welcomed), and why I am not pinning the version. What I find very surprising is that we are now (when not setting a version) defaulting to an *unstable* version (1.26*rc1*), instead of a *stable* one (1.25). Let me pose a hypothetical situation, if someone tomorrow sends a patch changing the *package name* of `guile-next' to simply `guile', would you be fine with merging it (sure, let us assume there is a deprecation period for the guile-next *package name*)? Based on your reasoning above it should be fine, since the variable name does not change? And if user wanted specific version, he should have said so, correct? -- For the record, I *expect* you to object to ^. But I do not understand based on what logic, given your argumentation above. So please enlighten me. Thank you for having patience with me, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
