Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the fix is applied in
v1.31.2
, we probably want:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea but the idea is to release only the retraction in
v1.31.2
, quickly after you verified that a potential harmful bug exists in the release, until you release the actual fix. To prevent more people to upgrade to this version until the fix is released. Maybe it's already late for this bug but good to adopt the process for future.from https://go.dev/ref/mod#go-mod-file-retract
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the
retract
should be added to the next release (likelyv1.31.2
) and I believe only then can the Go tooling knows about those.But we want to prevent or warn a user from upgrading to
v1.31.0
orv1.31.1
(where the producer deadlock can happen).If we have
retract v1.31.2
then that version (with a fix) would not be considered when installing@latest
and becausev1.31.1
is not retracted then it would be picked instead.I never use that feature but that is my understanding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a range so it includes "1.31.1" as well. The idea is that if you merge this and release it as "1.31.2" then when a user uses go tooling to "upgrade" or get the latest version, because 1.31.0, 1.31.1 and 1.31.2 are retracted, 1.30.1 will be considered as the latest.
So for example if a user is currently using 1.31.1 they will be "upgraded" to 1.30.1.
After you release the fix in 1.31.3 everything will be back to normal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got it now 🤦, I was expecting
v1.31.2
being the next release to contain the bugfix and I was not interpreting theretract
directive to be a range.Depending on how long it takes to verify/approve the fix, it might makes sense to release
v1.31.2
with this change to prevent users (using a recent enough version of Go) from pulling those versions.We just want to make sure we update the range if the fix makes it to
v1.31.2
.