Re: Deprecating old Go versions (and the ports that use them)

On Fri, Dec 5, 2025 at 10:04 AM Robert Clausecker <[email protected]> wrote:

> Am Fri, Dec 05, 2025 at 09:47:54AM -0500 schrieb Adam Weinberger:
> > Hi everyone,
> >
> > I just scheduled 3/4 of our Go ports for removal, along with 75 ports. I
> > want to explain why, and what we should do about it.
> >
> > TL;DR--75 ports need to try altering USES=go:1.2x -> USES=go, because
> > likely none of the ports actually need to be deleted!
> >
> > This is going to cause a scramble up-front here, but it's for our own
> good.
> >
> > ============================
> > Why are we deleting Go versions?
> > ============================
> >
> > Go supports only the latest two minors. All minors older than that have
> > known bugs and security holes that will never be fixed. Currently we
> > provide SIX minors, which frankly is irresponsible. I'm going to start
> > being aggressive about culling old Go versions.
> >
> > Currently, these 75 ports (plus another 68 for go1.24, and 51 for 1.25)
> pin
> > themselves to a Go version with
> >
> >     USES=go:1.23
> >
> > This *almost always* stems from a misunderstanding:
>
> The reason all these ports do that is that there is no USES=go:1.23+, so
> when you need go version 1.23 and 1.22 is the default, you must put in
> go:1.23 or the port won't build.
>

That's the misunderstanding. Go 1.22 is fully capable of building software
written for 1.23. A go.mod that says "go 1.24" isn't saying "I require go
1.24," it is a hint to the compiler saying "Use the go 1.24 feature set",
which is fully available to any go version since (IIRC) 1.21.

Go ports will either build only with a particular version, or with any
version (at least, by design that's what it's supposed to do). I haven't
met any go ports written for go 1.25 that fail to build on go 1.24. When a
port requires the go 1.25 stdlib, it simply compiles with the 1.25 feature
set (for ≥ 1.25) or downloads the newer stdlib as part of the fetch phase
(for < 1.25).

This sort of thing can be 100% avoided by adding support for "this version
> of the go toolchain or any later version" to the ports framework so that
> people can tag their intent precisely.


This sort of thing can be 100% avoided by not using a version specifier at
all. What is the virtue of "1.23+" when go 1.23 is going away in a month
(and go 1.24 is going away in about 3 months)?


-- 
Adam Weinberger
[email protected]