Skip to content
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

Yank some versions of OptimizationBase #107391

Merged

Conversation

gdalle
Copy link
Contributor

@gdalle gdalle commented May 22, 2024

This PR yanks three consecutive versions of OptimizationBase (v0.0.6, v0.0.7, v1.0.0) because they incorrectly promised compatibility with ADTypes v1.

Question: is this necessary, or would a patch release be enough? My fear is that the patch release v0.0.8 is incompatible with v0.0.7, and so some people would not automatically get it (due to the double leading zero). Am I reading that correctly?

See also:

@gdalle gdalle marked this pull request as draft May 22, 2024 10:59
@devmotion
Copy link
Contributor

See https://github.com/JuliaRegistries/General?tab=readme-ov-file#when-is-yanking-a-release-appropriate:

There is however, a special category of bugged releases that can not be resolved by having a patch release. These also may to be resolved by yanking. That special category is when the compat bounds have been set too wide. i.e. say v2.10.0 was released using a feature not on julia v1.6 but the compat entry for julia was not raised in the release. In this case releasing a v2.10.1 with the corrected julia compat would not solve the issue as on julia v1.6 Pkg would still resolve the broken v2.10.0, and as a minor bump, reverting the code changes would not be valid in a patch bump. In this case one may either submit a PR to retroactively adjust the compat bounds of previous versions (best user-facing results, but slow and error-prone to implement) or yank the offending release.

@gdalle
Copy link
Contributor Author

gdalle commented May 22, 2024

What do you conclude from this? That yanking is indeed necessary here?

@Vaibhavdixit02
Copy link
Contributor

Yeah based on what David has quoted above it does seem yanking is necessary so I am okay with this

@gdalle gdalle marked this pull request as ready for review May 22, 2024 12:32
@devmotion
Copy link
Contributor

IMO based on the README yanking would be fine, but (if maintainers - and user? - prefer it) something like #107409 could be an alternative.

@gdalle gdalle marked this pull request as draft May 22, 2024 14:26
@Vaibhavdixit02
Copy link
Contributor

Tbh I had just overlooked the part that you can retrospectively change the compat bounds. I don't quite get what errors can be expected mentioned there?

@gdalle
Copy link
Contributor Author

gdalle commented May 22, 2024

I'm just wary (and I guess David too) because the syntax of compat bounds is slightly harder to get right than just yanked=true

@ChrisRackauckas ChrisRackauckas marked this pull request as ready for review May 23, 2024 02:56
@ChrisRackauckas
Copy link
Member

Yank is fine given there are versions before and after. Thanks for going through with this, sorry it took awhile to get to reviewing.

@ChrisRackauckas ChrisRackauckas merged commit 11ee18d into JuliaRegistries:master May 23, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants