Go dropping support for macOS <= 11.0 in Go 1.23

Upstream issue: https://github.com/golang/go/issues/64207

It looks like we are currently in undefined-behaviour land on 10.15 <= macOS < 11.0 in the Tor Browser Alpha channel.

We should probably expect PTs to stop working on older macOS platforms at some point in the 128 ESR channels. For the legacy 115 ESR macOS branch I suppose the newest we can supportedly upgrade to is 1.22

@meskio: do any of our PTs require 1.23 (or newer) yet?

/cc @boklm @pierov

added Build System MacOS Needs Information labels

assigned to @meskio

changed title from Go dropping support for macOS <= 10.15 in Go 1.23 to Go dropping support for macOS <= 11.0 in Go 1.23

changed the description

Go 1.22 is supported until February 2025.

I think we could simply revert to Go 1.22 unless 1.23 is required by anything.

Go people are becoming worse than Rust.

No, 1.23 is not required by any of our PTs for now. They all require 1.21.

@meskio actually can you confirm the required versions needed? We are using 1.20 on Windows for everything except Snowflake.

I thought 1.20 was for windows 7 which is being deprecated in TB14, isn't it?

All PTs depend on 1.21 currently. If you do have any reason to use 1.20 we'll explore if we can give support for that version, but that will require us not updating our dependencies.

That's the only reason... But we'll support 14.0 + 13.5 until March, as Mozilla extended the support for 115 until then.

Are there security fixes and/or improvements on our side for the new version, or is it a dependency update? In other words, what are the risks of shipping an older version of lyrebird until March to some clients?

Another possibility is to patch one of the first versions of Go 1.21 to restore Windows 7 compatibility. A forum user found the Go commit that made our PTs not work and managed to get Snowflake built with 1.21 working on Windows 7 after reverting it. We can try also for lyrebird maybe.

The only reason not to do it is that there might be other patches causing crashes. Also, we should check why the patch was added in the first place (using a nicer API, or did it improve the RNG quality?).

That's the only reason... But we'll support 14.0 + 13.5 until March, as Mozilla extended the support for 115 until then.

Do 14.0 and 13.5 share the go version? Or can you use a different version to build lyrebird in 13.5 and 14.0.

Are there security fixes and/or improvements on our side for the new version, or is it a dependency update? In other words, what are the risks of shipping an older version of lyrebird until March to some clients?

As we discussed by email is fine to keep lyrebird 0.3.0 in 13.5 as there is no security fixes just dependency updates. And I will do 0.3.x releases if any security problem appears so 13.5 has an updated version of lyrebird.

But I thought we could ship lyrebird 0.4.0 with go 1.21 in 14.0, should we keep also the version of lyrebird in 14.0 with 1.20? Will having a different version of lyrebird here complicate the things for you?

Another possibility is to patch one of the first versions of Go 1.21 to restore Windows 7 compatibility.

No, let's avoid doing that work.

Do 14.0 and 13.5 share the go version? Or can you use a different version to build lyrebird in 13.5 and 14.0.

No. They will have two separate maintenance branches, so we can keep 1.20 + Lyrebird 0.3.0 on the maintenance branch for 13.5.

No additional complications at all, we just wanted to be sure lyrebird will keep working.

removed Needs Information label

added 14.0 stable Next labels

assigned to @morgan and unassigned @meskio

marked this issue as related to #41262 (closed)

mentioned in merge request !1063 (merged)

closed

marked this issue as related to #41272 (closed)

removed the relation with #41262 (closed)

mentioned in issue #41345 (closed)

marked this issue as related to #41386 (closed)