Date: Fri, 5 Dec 2025 10:11:54 -0500 From: Adam Weinberger <adamw@adamw.org> To: Robert Clausecker <fuz@fuz.su> Cc: freebsd-go@freebsd.org, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: Deprecating old Go versions (and the ports that use them) Message-ID: <CAP7rwciFLATiUtQVN4EQMgphC1skFUzz2c=r3PN5ZZcoERBCRw@mail.gmail.com> In-Reply-To: <aTL0jHRDr-Ndg3SM@fuz.su> References: <CAP7rwcj-h0xUJ6QJMVfi6JE3h1SDN44J43qzBgtWLUFS3EYdJQ@mail.gmail.com> <aTL0jHRDr-Ndg3SM@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Fri, Dec 5, 2025 at 10:04 AM Robert Clausecker <fuz@fuz.su> 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 adamw@adamw.org [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 5, 2025 at 10:04 AM Robert Clausecker <<a href="mailto:fuz@fuz.su">fuz@fuz.su</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Fri, Dec 05, 2025 at 09:47:54AM -0500 schrieb Adam Weinberger:<br> > Hi everyone,<br> > <br> > I just scheduled 3/4 of our Go ports for removal, along with 75 ports. I<br> > want to explain why, and what we should do about it.<br> > <br> > TL;DR--75 ports need to try altering USES=go:1.2x -> USES=go, because<br> > likely none of the ports actually need to be deleted!<br> > <br> > This is going to cause a scramble up-front here, but it's for our own good.<br> > <br> > ============================<br> > Why are we deleting Go versions?<br> > ============================<br> > <br> > Go supports only the latest two minors. All minors older than that have<br> > known bugs and security holes that will never be fixed. Currently we<br> > provide SIX minors, which frankly is irresponsible. I'm going to start<br> > being aggressive about culling old Go versions.<br> > <br> > Currently, these 75 ports (plus another 68 for go1.24, and 51 for 1.25) pin<br> > themselves to a Go version with<br> > <br> > USES=go:1.23<br> > <br> > This *almost always* stems from a misunderstanding:<br> <br> The reason all these ports do that is that there is no USES=go:1.23+, so<br> when you need go version 1.23 and 1.22 is the default, you must put in<br> go:1.23 or the port won't build.<br></blockquote><div><br></div><div style="font-family:arial,sans-serif" class="gmail_default">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.</div><div style="font-family:arial,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,sans-serif" class="gmail_default">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).</div><div style="font-family:arial,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This sort of thing can be 100% avoided by adding support for "this version<br> of the go toolchain or any later version" to the ports framework so that<br> people can tag their intent precisely.</blockquote></div><div><br></div><div><div style="font-family:arial,sans-serif" class="gmail_default">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)?</div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Adam Weinberger</div><div><a href="mailto:adamw@adamw.org" target="_blank">adamw@adamw.org</a></div></div></div></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP7rwciFLATiUtQVN4EQMgphC1skFUzz2c=r3PN5ZZcoERBCRw>