On Fri, Feb 3, 2023 at 9:40 AM robert engels <
ren...@ix.netcom.com> wrote:
>
> I’d like to understand this a bit better as well. I currently develop an OSX app using Xcode/Obj-C and it runs all the way back to 10.9 (I recently raised the requirement from 10.7).
>
> Is the restriction only that the Go tool chain needs 10.15, but the produced binaries will work on an earlier version? Because that seems reasonable.
>
> Or do I have to use an old version of Go to produce binaries that run on an old version of OSX? This seems highly restrictive and harkens to the days of M$ and the continual upgrade cycles that churned through resources.
What dropping support means is that we no longer fix bugs that only
occur on unsupported releases, and we no longer run our tests on old
releases. That includes both running the Go tools, and running
programs produced by the Go tools.
We don't go out of our way to cause Go to break on unsupported
releases. That said, there are occasionally cases where we change Go
to require APIs that are only available on newer releases. That has
happened on macOS in the sense that we no longer support 386 or arm at
all; we only support amd64 and arm64. I don't know offhand if there
have been other such cases for macOS (there have been for Linux: for
example, we now require the accept4 system call to be supported
(except on arm)).
Our position is that it is actually Apple that is driving the upgrade
cycle you mention, not us. Apple chose to drop support for High
Sierra back in 2020, so anybody running a High Sierra system connected
to the Internet is at risk. Should we invest our limited resources on
supporting releases that even Apple has declined to support? If Apple
continued to support High Sierra, so would we.
Ian