go 1.18

[stefanb]

Final release build of the Go 1.18.

See

• Release notes: https://go.dev/doc/go1.18
• Blog post https://go.dev/blog/go1.18
• Download page: https://go.dev/dl/

Earlier pre-releases were result of a discussion Homebrew/discussions#2618 after #90350

[Bo98]

Thanks. We'll probably get more useful data when rc1 lands (right now upstreams won't have had a chance to fix any issues yet) but this'll still be useful to see how much is broken. There's a few long running PRs in the queue I want to prioritise CI time for first, so I'll start the CI for this at the weekend.

[gedw99]

Hey

Is it possible that this can be committed so it is easy to try go 1.8 beta1 ?
When a developer installs golang using brew it can still default to install go 1.7.5, so no one gets broken.

I guess the naming convention would then be "1.18beta1" and so used like:

brew install [email protected]
	brew info go
	brew switch go 1.18beta1

[iMichka]

Is it possible that this can be committed so it is easy to try go 1.8 beta1 ?

Not in homebrew-core, because this implies the homebrew maintainers are accepting to maintain it and fix bugs. We only ship "stable" versions.

If someone wants to ship beta versions of go, this can be done in an external tap: https://docs.brew.sh/Taps

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[SMillerDev]

Cancelled CI since the objections to betas still apply

[stefanb]

Sure, not to be merged, but tested at least?

[billinghamj]

Maybe worth bumping to beta 2 now @stefanb?

[SMillerDev]

I'd also like to suggest that some of the effort is directed at getting projects to use pre-releases in their CI. Upstream knowing about issues is half the battle, and not everyone is using Homebrew.

[billinghamj]

@SMillerDev This is obviously a far bigger issue/question, but I think that would likely be achieved most effectively if a fairly large number of Homebrew users switched to using beta versions of key runtimes like Go - including with all downstream formulas

If Homebrew had some kind of support for opting in to upcoming runtime versions (switching to build-from-source for those users, assuming you wouldn't want to use the build time on bottling), it would mean that day-to-day use would uncover incompatibilities & release blockers much earlier

As languages like Go get bigger and bigger, this issue will only get worse, so it seems worthwhile to consider something a little beyond Homebrew's usual approach

[SMillerDev]

This is obviously a far bigger issue/question, but I think that would likely be achieved most effectively if a fairly large number of Homebrew users switched to using beta versions of key runtimes like Go - including with all downstream formulas

This creates an unmanageable burden on Homebrew maintainers to keep track of beta software while the real developers responsible still don't know about the issue unless a homebrew user reports it. CI is a better tool for this then breaking people's local install.

If Homebrew had some kind of support for opting in to upcoming runtime versions (switching to build-from-source for those users, assuming you wouldn't want to use the build time on bottling), it would mean that day-to-day use would uncover incompatibilities & release blockers much earlier

And report them to Homebrew, where the community would have to figure out who's bug it is rather than when upstream has a pre-release in their CI.

As languages like Go get bigger and bigger, this issue will only get worse, so it seems worthwhile to consider something a little beyond Homebrew's usual approach

That's why we're allowing experimenting with release candidates now. It means that we get to know what works with the next stable as soon as it's nearing stable releases.

[danilobuerger]

rc1 is out

[billinghamj]

  url "https://go.dev/dl/go1.18rc1.src.tar.gz"
  mirror "https://fossies.org/linux/misc/go1.18rc1.src.tar.gz"
  sha256 "5cec7a6653008fa85f8821b33665de37be289b7a02f17f36f705a88c43980bb8"

For anyone wanting that

[stefanb]

Bumped to rc1

[danilobuerger]

@SMillerDev how can we get CI to run this now that rc1 is out?

[SMillerDev]

No need to tag me, or anyone else. People will read this when they have time.

https://github.com/Homebrew/homebrew-core/blob/master/audit_exceptions/unstable_allowlist.json defines exceptions for pre-releases.

[danilobuerger]

No need to tag me, or anyone else. People will read this when they have time.

@SMillerDev Without having tagged you, I probably wouldn't have found out about the allowlist. So thanks for pointing that out. Not everybody has your level of experience with homebrew.

[SMillerDev]

You would have, when I read the homebrew backlog today and answered.

Right now your tagging send a notification that interrupted a dinner with my family. And your question by far wasn't important enough to warrant that.

[danilobuerger]

It must be fun working with you 🙄.

[gonzaloserrano]

Once #94895 is merged it would be great to run 1.18-rc1 in CI.

It's adding that version to audit_exceptions/unstable_allowlist.json the correct way to do that?

Thanks

[samford]

To save folks from having to dig through the Actions history, the latest full run (from 1.18 RC1) appears to be https://github.com/Homebrew/homebrew-core/actions/runs/1967474524

Open Go-related PRs can be found by checking the "go" label (though these aren't limited to 1.18 fixes): https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+is%3Aopen+label%3Ago

I'm not sure there is any 1.18 full run yet. Wasn't the latest available about go1.18rc1?

Correct, there hasn't been a full run for 1.18 and the previous run was for 1.18 RC1. Bo was planning to start a run for 1.18 after fixing some of the issues from RC1, so I believe that's where things stand at the moment.

[georgettica]

Unrelated but still important, if you are here and following this to know when the PR is merged, you can change the notification type to be on closed so you will get pregnant bged only once when this is completed

[roopakv]

For formulae having upstream dev activity but not yet on 1.18, I propose the following and would love to hear if that is an ok next step:

• Open Issue on the repo asking them to support 1.18 and that if they dont by the time 1.19 comes out they will be deprecated from brew
• Have an overarching issue in Homebrew which links to all above issues ^
• Update to use [email protected] here in brew to unblock 1.18

The reason I suggest this is that the introduction of things like generics has broken a lot of linting and that is the issue in moving to 1.18. I tried for a few packages :)

If people are Ok with this i can work on this over the weekend. @Bo98 and other maintainers curious what your thoughts are.

[Bo98]

Thanks for all the hard work! I and most others really appreciate the effort and brew. I am patiently excited to brew my way into a future with generics

Thanks for the kind words. To be honest, when dealing with Go pull requests I tend to avoid checking emails/notifications while working on it since it's not the first time I've had people get quite angry at me. I didn't even bother opening the 1.17 PR last time and left it to others.

As a general update for those interested, two large GitHub Actions outages in two days at the same time of day when I would've been working on this has really not helped. I've done another late-night batch now though, and hopefully tomorrow will be better. I have already opened PRs fixing over half of the breakages - so we're already tackling this much quicker than 1.17.

For formulae having upstream dev activity but not yet on 1.18, I propose the following and would love to hear if that is an ok next step:

• Open Issue on the repo asking them to support 1.18 and that if they dont by the time 1.19 comes out they will be deprecated from brew

• Have an overarching issue in Homebrew which links to all above issues ^

• Update to use [email protected] here in brew to unblock 1.18

Yes, this is the approach I'd like to take, though I'm doing it in reverse order on this occasion. If the process works, we will do it again for 1.19 and later, and hopefully get a lot of that migrating work done between rc1 and final. Overall, it would make future Go releases quicker to merge, but will only work if we are able to follow through with your first point: trying to get 1.18 support before 1.19 (and crucially: raising a bug report and/or patch soon rather than at the last minute), and this is where the community's help will be key since that'll be time consuming for any one person to do alone.

What if, going forward, it would be a requirement that all Formulaes dependent on go were to use pinned versions ([email protected], [email protected] ... etc) instead, wouldn't that allow to upgrade the go Formulae to the latest version as soon as it is released upstream ?

The number of Go packages which need migrating to 1.17 is significantly less than the number that can stay on 1.18. In the long term, this is actually more work - even if it's less in the short team of merging a 1.18 PR. It's why I'm quite keen to try something in the middle (like the approach mentioned above), where we should be able to still have minimal long-term migratory work but achieve quick merge times by having a good strategy to take into rc1 testing where we know what to do, what to migrate and can perform all that before the final is released (we didn't really have a strategy for 1.18rc1 until after 1.18 final was released). The final release could also be tested less comprehensively (assuming there's no upstream breaking changes between rc1 and final) and thus take less time in CI.

It's also worth nothing the number of packages which break can vary between Go updates. The breakages for 1.18 is higher than usual due to a backwards incompatible change made affecting x/sys, which was unfortunately very highly used. It's possible 1.19 could break hardly anything - we'll test this come 1.19rc1.

---

For all: I know the release process hasn't been great, but I'm trying things now that could improve it in the future. Time will tell with 1.19's release.

For those who follow patch releases for Go, I'm hoping for a significantly streamlined process for that soon with smarter testing (currently all releases are treated the same by the CI).

[andig]

Yes, this is the approach I'd like to take, though I'm doing it in reverse order. If the process works, we will do it again for 1.19 and later, and potentially even get a lot of that migrating work done between rc1 and final. Overall, it would make future Go releases quicker to merge, but will only work if we are able to follow through with your first point: trying to get 1.18 support before 1.19 (and raising a bug report and/or patch soon rather than at the last minute).

That‘s a great approach but unfortunately still won‘t help with the packages broken due to re-releases (checksum mismatch) etc which seems to be a good portion in earlier releases. In discussions I had tried to suggest to add some tooling for those to automate the process (i.e. open upstream issue on checksum mismatch, potentially accept/release if confirmed or not confirmed in time). I still feel some more automation might lessen the burden with these.

[Bo98]

That‘s a great approach but unfortunately still won‘t help with the packages broken due to re-releases

There is only one such formula like that (already fixed) this time, but there's usually a month between rc1 and final so there should be enough time to sort them. It anything new pops up this next run like that, it will not be a blocker for merging.

what do you think about creating a formula for each version like we have already (go1.16, go1.17 etc.) and stay with with the "default" go formula to the latest version (for time between new release versions see below).

I've already touched on this above. If we can make good use of rc1 next time, this might not be necessary.

[Bo98]

Ok got 120+ breakages down to 4. I think I can merge this and quickly fix them after merge.

• Have an overarching issue in Homebrew which links to all above issues

I will do this on Monday and link here, but it's basically the output of brew uses --include-build [email protected] minus anything already deprecated.

I am however hopeful we can potentially get this merged as soon as this week if we fix the failed dependents over the next couple days.

Hey, exactly as hoped for! Only took 4 days, and a couple of that were affected by CI outages.

[BrewTestBot]

@Bo98 has triggered a merge.

[Moulick]

spicetify/cli#1547 upgraded to go 1.18