-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go 1.18 #91369
go 1.18 #91369
Conversation
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. |
Hey Is it possible that this can be committed so it is easy to try go 1.8 beta1 ? I guess the naming convention would then be "1.18beta1" and so used like:
|
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 |
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. |
Cancelled CI since the objections to betas still apply |
Sure, not to be merged, but tested at least? |
Maybe worth bumping to beta 2 now @stefanb? |
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. |
@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 |
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.
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.
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. |
rc1 is out |
For anyone wanting that |
Bumped to rc1 |
@SMillerDev how can we get CI to run this now that rc1 is out? |
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. |
@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. |
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. |
It must be fun working with you 🙄. |
Once #94895 is merged it would be great to run 1.18-rc1 in CI. It's adding that version to Thanks |
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
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. |
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 |
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:
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. |
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.
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.
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). |
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. |
This comment was marked as duplicate.
This comment was marked as duplicate.
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.
I've already touched on this above. If we can make good use of rc1 next time, this might not be necessary. |
Ok got 120+ breakages down to 4. I think I can merge this and quickly fix them after merge.
I will do this on Monday and link here, but it's basically the output of
Hey, exactly as hoped for! Only took 4 days, and a couple of that were affected by CI outages. |
@Bo98 has triggered a merge. |
spicetify/cli#1547 upgraded to go 1.18 |
Final release build of the Go 1.18.
See
Earlier pre-releases were result of a discussion Homebrew/discussions#2618 after #90350