Date: Fri, 5 Dec 2025 20:52:30 +0100 From: Daniel Engberg <diizzy@FreeBSD.org> To: Adam Weinberger <adamw@adamw.org>, freebsd-go@freebsd.org, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: Deprecating old Go versions (and the ports that use them) Message-ID: <35abf601-f72c-42fd-9c41-121eb3ae71d3@FreeBSD.org> In-Reply-To: <CAP7rwcj-h0xUJ6QJMVfi6JE3h1SDN44J43qzBgtWLUFS3EYdJQ@mail.gmail.com> References: <CAP7rwcj-h0xUJ6QJMVfi6JE3h1SDN44J43qzBgtWLUFS3EYdJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 2025-12-05 15:47, Adam Weinberger wrote: > 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: > > ******************************** > When a go.mod says "go 1.23" that means it needs AT LEAST 1.23, *NOT* > a need to pin it to 1.23! > ******************************** > > ============================ > FACT: 99% of Go ports do not need a version pin! > ============================ > > Go added a major new feature back in 1.21 (IIRC) where new versions of > Go can build software targeting older versions, by restricting its > build features and quirks to emulate those of the target version. In > other words, go1.25 can happily build software written for go1.23. > > Additionally, Go added support for building a FUTURE version. In other > words, go1.23 can happily build software written for go1.25! You may > see some builds that say "Downloading go-1.25"---this is the build > system doing the right thing, downloading and utilizing the newer stdlib. > > ============================ > A port I maintain, or a port I care about, is scheduled for deletion. > What should I do? > ============================ > > First and foremost, try a test build with the version specifier > removed. In other words, change: > USES= go:1.23 > to > USES=. go > > and > USES=. go:1.23,modules > to > USES=. go:modules > > If it builds successfully, either commit it, or submit a PR, or at the > very least reach out to the Go team. > > If it doesn't work, check for updates upstream! You can try pinning to > a newer version (ex. USES=go:1.24), but be aware that it will still > get deleted when go1.24 gets deleted. > > This means that: > ********************************** > Any port with a pinned version will last at most 1 year in the ports tree! > ********************************** > > Go releases two minors a year, so any version-pinned port will last > until two future minors, which is at most a year away. > > ============================ > Can't we turn USES=go:1.23 or USES=go:1.23+ to mean >1.23? > ============================ > > Not really. We really do need a way to pin versions for when a package > simply cannot build with a newer version, but most importantly, the > right approach to version pinning is not to do it in the first place. > > If you have questions, concerns, or thoughts, please reach out to > go@FreeBSD.org (or reply here). > > I'll reach out to individual maintainers with this same information. > > > -- > Adam Weinberger > adamw@adamw.org Hi, The issue with this approach is that it breaks dependency tracking and expected behavior within in the ports repo, concerns which have been brought up before [1]. Indirectly it also show yet again that we need to have a sane deprecation policy within the tree. If port X doesn't build with a supported "compiler" it either needs to be patched (preferably upstream and the pulled in downstream) or it needs to go. If you install GCC 14 you don't except it to download and use GCC 11 instead. While this might clash with Go(lang)'s idea of an ecosystem that's how we package ports and how people expect ports to work. Going with the information above why not patch go.mod on the fly to match the current compiler version being used? If it breaks patch or mark it as broken and move on. Best regards, Daniel 1: https://reviews.freebsd.org/D49906 [-- Attachment #2 --] <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 2025-12-05 15:47, Adam Weinberger wrote:<br> </div> <blockquote type="cite" cite="mid:CAP7rwcj-h0xUJ6QJMVfi6JE3h1SDN44J43qzBgtWLUFS3EYdJQ@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div> <div style="font-family:arial,sans-serif" class="gmail_default">Hi everyone,</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">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.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">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!</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">This is going to cause a scramble up-front here, but it's for our own good.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default">Why are we deleting Go versions?</div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">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.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">Currently, these 75 ports (plus another 68 for go1.24, and 51 for 1.25) pin themselves to a Go version with</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default"> USES=go:1.23</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">This *almost always* stems from a misunderstanding:</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">********************************</div> <div style="font-family:arial,sans-serif" class="gmail_default">When a go.mod says "go 1.23" that means it needs AT LEAST 1.23, *NOT* a need to pin it to 1.23!</div> <div style="font-family:arial,sans-serif" class="gmail_default">********************************</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default">FACT: 99% of Go ports do not need a version pin!</div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">Go added a major new feature back in 1.21 (IIRC) where new versions of Go can build software targeting older versions, by restricting its build features and quirks to emulate those of the target version. In other words, go1.25 can happily build software written for go1.23.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">Additionally, Go added support for building a FUTURE version. In other words, go1.23 can happily build software written for go1.25! You may see some builds that say "Downloading go-1.25"---this is the build system doing the right thing, downloading and utilizing the newer stdlib.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default">A port I maintain, or a port I care about, is scheduled for deletion. What should I do?</div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">First and foremost, try a test build with the version specifier removed. In other words, change:</div> <div style="font-family:arial,sans-serif" class="gmail_default"> USES= go:1.23</div> <div style="font-family:arial,sans-serif" class="gmail_default">to</div> <div style="font-family:arial,sans-serif" class="gmail_default"> USES=. go</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">and</div> <div style="font-family:arial,sans-serif" class="gmail_default"> USES=. go:1.23,modules</div> <div style="font-family:arial,sans-serif" class="gmail_default">to</div> <div style="font-family:arial,sans-serif" class="gmail_default"> USES=. go:modules</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">If it builds successfully, either commit it, or submit a PR, or at the very least reach out to the Go team.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">If it doesn't work, check for updates upstream! You can try pinning to a newer version (ex. USES=go:1.24), but be aware that it will still get deleted when go1.24 gets deleted.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">This means that:</div> <div style="font-family:arial,sans-serif" class="gmail_default">**********************************</div> <div style="font-family:arial,sans-serif" class="gmail_default">Any port with a pinned version will last at most 1 year in the ports tree!</div> <div style="font-family:arial,sans-serif" class="gmail_default">**********************************</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">Go releases two minors a year, so any version-pinned port will last until two future minors, which is at most a year away.</div> <br clear="all"> </div> <div>============================</div> <div> <div style="font-family:arial,sans-serif" class="gmail_default">Can't we turn USES=go:1.23 or USES=go:1.23+ to mean >1.23?</div> <div style="font-family:arial,sans-serif" class="gmail_default">============================</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">Not really. We really do need a way to pin versions for when a package simply cannot build with a newer version, but most importantly, the right approach to version pinning is not to do it in the first place.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">If you have questions, concerns, or thoughts, please reach out to <a class="moz-txt-link-abbreviated" href="mailto:go@FreeBSD.org">go@FreeBSD.org</a> (or reply here).</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <div style="font-family:arial,sans-serif" class="gmail_default">I'll reach out to individual maintainers with this same information.</div> <div style="font-family:arial,sans-serif" class="gmail_default"><br> </div> <br> </div> <span class="gmail_signature_prefix">-- </span><br> <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"> <div dir="ltr"> <div> <div dir="ltr"> <div>Adam Weinberger</div> <div><a href="mailto:adamw@adamw.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">adamw@adamw.org</a></div> </div> </div> </div> </div> </div> </blockquote> Hi, <p>The issue with this approach is that it breaks dependency tracking and expected behavior within in the ports repo, concerns which have been brought up before [1]. Indirectly it also show yet again that we need to have a sane deprecation policy within the tree. If port X doesn't build with a supported "compiler" it either needs to be patched (preferably upstream and the pulled in downstream) or it needs to go.</p> <p>If you install GCC 14 you don't except it to download and use GCC 11 instead. While this might clash with Go(lang)'s idea of an ecosystem that's how we package ports and how people expect ports to work.<br> <br> Going with the information above why not patch go.mod on the fly to match the current compiler version being used? If it breaks patch or mark it as broken and move on.<br> <br> Best regards,<br> Daniel</p> <p>1: <a class="moz-txt-link-freetext" href="https://reviews.freebsd.org/D49906">https://reviews.freebsd.org/D49906</a></p>; </body> </html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35abf601-f72c-42fd-9c41-121eb3ae71d3>