-
-
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.17.5 #90350
go 1.17.5 #90350
Conversation
Why were tests cancelled? |
@Loyalsoldier Tests have a timeout of 60 minute unless maintainers allow longer CI runs (by labelling the PR), to ensure CI machines aren't blocked by too many concurrent long runs. |
We already have two long-running CI jobs at the moment. A third one is going to cause huge delays, so we can restart this when those jobs are done. |
Go 1.17.4 is now officially released. It fixes a nasty crash on mac OS Monterey (apparent kernel bug.) How can I help get this released? |
Check all the failing dependent formulae and help fix them |
@SMillerDev where can we see that list? |
In the pull request "Checks" |
This seems to make the test hang indefinitely (e.g. Homebrew#90350). Let's also sleep for longer since short `sleep`s tend to cause trouble in CI.
fyi Go 1.17.5 was just released. Does that mean this PR should be closed and a new one opened? |
This one can also be updated |
closes Homebrew#90350
2fdcafa
to
77f3713
Compare
Most of tests
|
🤔 Q: why do all dependancies need to be checked and rebuilt? I have noticed this problem with the last few go upgrades, most notably with the major revisions, eg #83413 with a huge list of fixes to dependants, which should be up to dependants to sort out, and giving them upgraded go binary would actually help them detect and fix those problems earlier. |
But how will we know they don't break with the newest Go version if we don't try and build them with that version?
It is up to dependents to sort out, but if nobody checks if it works how would they ever know?
They can always run CI with pre-release Go builds to see if their software will stop working soon. Depending on Homebrew to suddendly break your build when you upgrade is just lazy and irrisponsible engineering. |
Do we need to know that when upgrading Go? Yes it is nice to know, but not essential for go upgrade and that can be dealt with later. Their current, already build version won't be affected in any way.
It will become obvious when somebody will eventually want to build the new dependant binary (either same or newer version, locally or when trying to bump the version in homebrew).
Yes, it is chicken and egg problem in a way, but current approach is blocking gradual evolution progress. |
I think we've had the argument before and it is probably better suited for discussions. I'd suggest here: Homebrew/discussions#2618 |
|
Let's ship this. A few issues have been fixed, I'll make a second pass for |
Thanks @Porkepix for the pull request. |
Thanks, everyone |
Created with
brew bump-formula-pr
.resource
blocks may require updates.