From Newsgroup: muc.lists.freebsd.ports

--000000000000cf8dea06453588be
Content-Type: text/plain; charset="UTF-8"

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

--000000000000cf8dea06453588be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div style=3D"font-family:arial,sans-serif" class=3D"= gmail_default">Hi everyone,</div><div style=3D"font-family:arial,sans-serif=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,sans-se= rif" class=3D"gmail_default">I just scheduled 3/4 of our Go ports for remov= al, along with 75 ports. I want to explain why, and what we should do about=
it.</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_defaul= t"><br></div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_def= ault">TL;DR--75 ports need to try altering USES=3Dgo:1.2x -&gt; USES=3Dgo, = because likely none of the ports actually need to be deleted!</div><div sty= le=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></div><div = style=3D"font-family:arial,sans-serif" class=3D"gmail_default">This is goin=
g to cause a scramble up-front here, but it&#39;s for our own good.</div><d=
iv style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></div= ><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default= ">Why are we deleting Go versions?</div><div style=3D"font-family:arial,san= s-serif" class=3D"gmail_default">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div style=3D"font-family:a= rial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-famil= y:arial,sans-serif" class=3D"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 irr= esponsible. I&#39;m going to start being aggressive about culling old Go ve= rsions.</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_def= ault"><br></div><div style=3D"font-family:arial,sans-serif" class=3D"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=3D"font-family:ar= ial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-family= :arial,sans-serif" class=3D"gmail_default">=C2=A0 =C2=A0 USES=3Dgo:1.23</di= v><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br><= /div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">Th=
is *almost always* stems from a misunderstanding:</div><div style=3D"font-f= amily:arial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"fon= t-family:arial,sans-serif" class=3D"gmail_default">************************= ********</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_de= fault">When a go.mod says &quot;go 1.23&quot; that means it needs AT LEAST = 1.23, *NOT* a need to pin it to 1.23!</div><div style=3D"font-family:arial,= sans-serif" class=3D"gmail_default">********************************</div><= div style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></di= v><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_defa= ult">FACT: 99% of Go ports do not need a version pin!</div><div style=3D"fo= nt-family:arial,sans-serif" class=3D"gmail_default">=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div s= tyle=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></div><di=
v style=3D"font-family:arial,sans-serif" class=3D"gmail_default">Go added a=
major new feature back in 1.21 (IIRC) where new versions of Go can build s= oftware targeting=C2=A0older versions, by restricting its build features an=
d quirks to emulate those of the target version. In other words, go1.25 can=
happily build software written for go1.23.</div><div style=3D"font-family:= arial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-fami= ly:arial,sans-serif" class=3D"gmail_default">Additionally, Go added support=
for building a FUTURE version. In other words, go1.23 can happily build so= ftware written for go1.25! You may see some builds that say &quot;Downloadi=
ng go-1.25&quot;---this is the build system doing the right thing, download= ing and utilizing the newer stdlib.</div><div style=3D"font-family:arial,sa= ns-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:arial= ,sans-serif" class=3D"gmail_default">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div style=3D"font-fa= mily:arial,sans-serif" class=3D"gmail_default">A port I maintain, or a port=
I care about, is scheduled for deletion. What should I do?</div><div style= =3D"font-family:arial,sans-serif" class=3D"gmail_default">=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>= <div style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></d= iv><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">Firs=
t and foremost, try a test build with the version specifier removed. In oth=
er words, change:</div><div style=3D"font-family:arial,sans-serif" class=3D= "gmail_default">=C2=A0 =C2=A0 USES=3D=C2=A0 =C2=A0 go:1.23</div><div style= =3D"font-family:arial,sans-serif" class=3D"gmail_default">to</div><div styl= e=3D"font-family:arial,sans-serif" class=3D"gmail_default">=C2=A0 =C2=A0 US= ES=3D.=C2=A0 =C2=A0go</div><div style=3D"font-family:arial,sans-serif" clas= s=3D"gmail_default"><br></div><div style=3D"font-family:arial,sans-serif" c= lass=3D"gmail_default">and</div><div style=3D"font-family:arial,sans-serif"=
class=3D"gmail_default">=C2=A0 =C2=A0 USES=3D.=C2=A0 =C2=A0go:1.23,modules= </div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">t= o</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">= =C2=A0 =C2=A0 USES=3D.=C2=A0 =C2=A0go:modules</div><div style=3D"font-famil= y:arial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-fa= mily:arial,sans-serif" class=3D"gmail_default">If it builds successfully, e= ither commit it, or submit a PR, or at the very least reach out to the Go t= eam.</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_defaul= t"><br></div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_def= ault">If it doesn&#39;t work, check for updates upstream! You can try pinni=
ng to a newer version (ex. USES=3Dgo:1.24), but be aware that it will still=
get deleted when go1.24 gets deleted.</div><div style=3D"font-family:arial= ,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:ar= ial,sans-serif" class=3D"gmail_default">This means that:</div><div style=3D= "font-family:arial,sans-serif" class=3D"gmail_default">********************= **************</div><div style=3D"font-family:arial,sans-serif" class=3D"gm= ail_default">Any port with a pinned version will last at most 1 year in the=
ports tree!</div><div style=3D"font-family:arial,sans-serif" class=3D"gmai= l_default">**********************************</div><div style=3D"font-famil= y:arial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-fa= mily:arial,sans-serif" class=3D"gmail_default">Go releases two minors a yea=
r, so any version-pinned port will last until two future minors, which is a=
t most a year away.</div><br clear=3D"all"></div><div>=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><= div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">Can&#39;=
t we turn USES=3Dgo:1.23 or USES=3Dgo:1.23+ to mean &gt;1.23?</div><div sty= le=3D"font-family:arial,sans-serif" class=3D"gmail_default">=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>= <div style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></d= iv><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">Not = really. We really do need a way to pin versions for when a package simply c= annot 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=3D"f= ont-family:arial,sans-serif" class=3D"gmail_default"><br></div><div style= =3D"font-family:arial,sans-serif" class=3D"gmail_default">If you have quest= ions, concerns, or thoughts, please reach out to go@FreeBSD.org (or reply h= ere).</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_defau= lt"><br></div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_de= fault">I&#39;ll reach out to individual maintainers with this same informat= ion.</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_defaul= t"><br></div><br></div><span class=3D"gmail_signature_prefix">-- </span><br= ><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatu= re"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Adam Weinberger</div><div><=
a href=3D"mailto:adamw@adamw.org" target=3D"_blank">adamw@adamw.org</a></di= v></div></div></div></div></div>

--000000000000cf8dea06453588be--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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.

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.

Yours,
Robert Clausecker
--
() ascii ribbon campaign - for an encoding-agnostic world
/\ - against html email - against proprietary attachments


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--0000000000008d5537064535dedf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 5, 2025 at 10:04=E2=80=AFAM Robert Clausecker <fuz@fuz.su> wrot=
e:

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=3Dgo:1.2x -> USES=3Dgo, becau=

se

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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D

Why are we deleting Go versions? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D

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=3Dgo:1.23

This *almost always* stems from a misunderstanding:

The reason all these ports do that is that there is no USES=3Dgo:1.23+, s=

o

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 =E2=89=A5 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)?


--=20
Adam Weinberger
adamw@adamw.org

--0000000000008d5537064535dedf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:arial,sans-serif"><br></div></div><br><div class=3D"gmail_quote gm= ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 5, 2= 025 at 10:04=E2=80=AFAM Robert Clausecker &lt;<a href=3D"mailto:fuz@fuz.su"= >fuz@fuz.su</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"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>
&gt; Hi everyone,<br>
&gt; <br>
&gt; I just scheduled 3/4 of our Go ports for removal, along with 75 ports.=
I<br>
&gt; want to explain why, and what we should do about it.<br>
&gt; <br>
&gt; TL;DR--75 ports need to try altering USES=3Dgo:1.2x -&gt; USES=3Dgo, b= ecause<br>
&gt; likely none of the ports actually need to be deleted!<br>
&gt; <br>
&gt; This is going to cause a scramble up-front here, but it&#39;s for our = own good.<br>
&gt; <br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D<br>
&gt; Why are we deleting Go versions?<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D<br>
&gt; <br>
&gt; Go supports only the latest two minors. All minors older than that hav= e<br>
&gt; known bugs and security holes that will never be fixed. Currently we<b=

&gt; provide SIX minors, which frankly is irresponsible. I&#39;m going to s= tart<br>
&gt; being aggressive about culling old Go versions.<br>
&gt; <br>
&gt; Currently, these 75 ports (plus another 68 for go1.24, and 51 for 1.25=
) pin<br>
&gt; themselves to a Go version with<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0USES=3Dgo:1.23<br>
&gt; <br>
&gt; This *almost always* stems from a misunderstanding:<br>

The reason all these ports do that is that there is no USES=3Dgo:1.23+, so<=

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&#39;t build.<br></blockquote><div><br></div><div st= yle=3D"font-family:arial,sans-serif" class=3D"gmail_default">That&#39;s the=
misunderstanding. Go 1.22 is fully capable of building software written fo=
r 1.23. A go.mod that says &quot;go 1.24&quot; isn&#39;t saying &quot;I req= uire go 1.24,&quot; it is a hint to the compiler saying &quot;Use the go 1.=
24 feature set&quot;, which is fully available to any go version since (IIR=
C) 1.21.</div><div style=3D"font-family:arial,sans-serif" class=3D"gmail_de= fault"><br></div><div style=3D"font-family:arial,sans-serif" class=3D"gmail= _default">Go ports will either build only with a particular version, or wit=
h any version (at least, by design that&#39;s what it&#39;s supposed to do)=
. I haven&#39;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 t=
he 1.25 feature set (for =E2=89=A5 1.25) or downloads the newer stdlib as p= art of the fetch phase (for &lt; 1.25).</div><div style=3D"font-family:aria= l,sans-serif" class=3D"gmail_default"><br></div><blockquote class=3D"gmail_= quote" style=3D"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 &quot;this ver= sion<br>
of the go toolchain or any later version&quot; to the ports framework so th= at<br>
people can tag their intent precisely.</blockquote></div><div><br></div><di= v><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">This = sort of thing can be 100% avoided by not using a version specifier at all. = What is the virtue of &quot;1.23+&quot; when go 1.23 is going away in a mon=
th (and go 1.24 is going away in about 3 months)?</div><br clear=3D"all"></= div><br><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"lt=
r" class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Ad=
am Weinberger</div><div><a href=3D"mailto:adamw@adamw.org" target=3D"_blank= ">adamw@adamw.org</a></div></div></div></div></div></div>

--0000000000008d5537064535dedf--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Dec 5, 2025, at 6:48rC>AM, Adam Weinberger <adamw@adamw.org> wrote:

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!

Dumb question: Why not unilaterally update all these ports to USES=go and commit
the ones that compile instead of removing them?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--000000000000b4073406453a5332
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 5, 2025 at 2:52=E2=80=AFPM Daniel Engberg <diizzy@freebsd.org> = wrote:

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

I'm really not advocating for any particular approach other than that we
badly need to remove old Go versions, which are blocked by ports with
pinned versions. I really don't care how we handle version selection moving forward (I mean, I *do* care, but right now I'm trying to clean up a mess before it catches fire), and I'll happily go along with any consensus.

Right now we have a collection of ports that depend on Go versions that absolutely shouldn't be in the tree, and in 3 months we are going to have
to do the same process with everything pinned to 1.24. And six months after that, do it again with 1.25.

So far today I've handled one message cursing at me, five emails where committers thought that petulant sarcasm would make them feel superior, two emails accusing me of gaslighting developers, one email mocking a paste
error that took longer to write than fixing it would have, about 6 emails asking for clarification (thanks to everyone who reached out!), I've lost
count of the number of messages about how the how the version system ought
to work, and one email from a committer saying they were offended that I
only provided a list of ports and it was too much work to remember which
port they maintained. I've had exactly one person reach out to say, "How
can I help?"

Daniel, I think your ideas are great, and I'm super eager for ANYONE to
step in and build a better system. Also, I appreciate your thoughtful
approach and constructive response.

Today, I'm trying to fix the problem of us providing Go versions that we shouldn't. I'm happy to work on fixing everything else tomorrow, if we
could please work on the highest-priority item first and maybe---just maybe---people could take a deep breath before sending me emails that are barely more than curse words. I agree that everyone is a better developer
than me---I've said this publicly many times---so it doesn't take a flame
email or a dose of witty sarcasm to feel superior, ok? (To be clear, NONE
of those last sentences applies to diizzy in any way.)


--=20
Adam Weinberger
adamw@adamw.org

--000000000000b4073406453a5332
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:arial,sans-serif">On Fri, Dec 5, 2025 at 2:52=E2=80=AFPM Daniel En= gberg &lt;<a href=3D"mailto:diizzy@freebsd.org">diizzy@freebsd.org</a>&gt; = wrote:</div></div><div class=3D"gmail_quote gmail_quote_container"><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div><p>The issue with this appro= ach 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&#39;t build with a supported &quot;compiler&quo=
t; 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&#39;t except it to download and use GC=
C
11 instead. While this might clash with Go(lang)&#39;s idea of an
ecosystem that&#39;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 href=3D"https://reviews.freebsd.org/D49906" target=3D"_blank">= https://reviews.freebsd.org/D49906</a></p>
</div>

</blockquote></div><div><br></div><div><div style=3D"font-family:arial,sans= -serif" class=3D"gmail_default">I&#39;m really not advocating for any parti= cular approach other than that we badly need to remove old Go versions, whi=
ch are blocked by ports with pinned versions. I really don&#39;t care how w=
e handle version selection moving forward (I mean, I *do* care, but right n=
ow I&#39;m trying to clean up a mess before it catches fire), and I&#39;ll = happily go along with any consensus.</div><div style=3D"font-family:arial,s= ans-serif" class=3D"gmail_default"><br></div><div style=3D"font-family:aria= l,sans-serif" class=3D"gmail_default">Right now we have a collection of por=
ts that depend on Go versions that absolutely shouldn&#39;t be in the tree,=
and in 3 months we are going to have to do the same process with everythin=
g pinned to 1.24. And six months after that, do it again with 1.25.</div><d=
iv style=3D"font-family:arial,sans-serif" class=3D"gmail_default"><br></div= ><div style=3D"font-family:arial,sans-serif" class=3D"gmail_default">So far=
today I&#39;ve handled one message cursing at me, five emails where commit= ters thought that petulant sarcasm would make them feel superior, two email=
s accusing me of gaslighting developers, one email mocking a paste error th=
at took longer to write than fixing it would have, about 6 emails asking fo=
r clarification (thanks to everyone who reached out!), I&#39;ve lost count =
of the number of messages about how the how the version system ought to wor=
k, and one email from a committer saying they were offended that I only pro= vided a list of ports and it was too much work to remember which port they = maintained. I&#39;ve had exactly one person reach out to say, &quot;How can=
I help?&quot;</div><div style=3D"font-family:arial,sans-serif" class=3D"gm= ail_default"><br></div><div style=3D"font-family:arial,sans-serif" class=3D= "gmail_default">Daniel, I think your ideas are great, and I&#39;m super eag=
er for ANYONE to step in and build a better system. Also, I appreciate your=
thoughtful approach and constructive response.</div><div style=3D"font-fam= ily:arial,sans-serif" class=3D"gmail_default"><br></div><div style=3D"font-= family:arial,sans-serif" class=3D"gmail_default">Today, I&#39;m trying to f=
ix the problem of us providing Go versions that we shouldn&#39;t. I&#39;m h= appy to work on fixing everything else tomorrow, if we could please work on=
the highest-priority item first and maybe---just maybe---people could take=
a deep breath before sending me emails that are barely more than curse wor= ds. I agree that everyone is a better developer than me---I&#39;ve said thi=
s publicly many times---so it doesn&#39;t take a flame email or a dose of w= itty sarcasm to feel superior, ok? (To be clear, NONE of those last sentenc=
es applies to diizzy in any way.)</div><br clear=3D"all"></div><br><span cl= ass=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmai= l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Adam Weinberger</d= iv><div><a href=3D"mailto:adamw@adamw.org" target=3D"_blank">adamw@adamw.or= g</a></div></div></div></div></div></div>

--000000000000b4073406453a5332--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2