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

Revert "Multi-interval set operators" #191

Merged
merged 2 commits into from
Jun 1, 2022
Merged

Conversation

rofinn
Copy link
Member

@rofinn rofinn commented Jun 1, 2022

Reverts #179

@rofinn rofinn requested a review from omus as a code owner June 1, 2022 16:06
Copy link
Member

@morris25 morris25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relevant comment for reversion #179 (comment)

@codecov
Copy link

codecov bot commented Jun 1, 2022

Codecov Report

Merging #191 (7f7fd0e) into master (7a7ec36) will decrease coverage by 2.90%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #191      +/-   ##
==========================================
- Coverage   84.63%   81.73%   -2.91%     
==========================================
  Files          12       11       -1     
  Lines         794      624     -170     
==========================================
- Hits          672      510     -162     
+ Misses        122      114       -8     
Impacted Files Coverage Δ
src/Intervals.jl 100.00% <ø> (ø)
src/endpoint.jl 98.11% <ø> (ø)
src/interval.jl 96.36% <100.00%> (+0.34%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a7ec36...7f7fd0e. Read the comment docs.

@rofinn rofinn merged commit cb4f4d5 into master Jun 1, 2022
@rofinn rofinn deleted the revert-179-dfl/set-operations branch June 1, 2022 16:31
@omus
Copy link
Collaborator

omus commented Jun 1, 2022

FYI the proper way to have handled this would have been to yank version 1.7.0 from the General registry instead of making a 1.7.1 release

@rofinn
Copy link
Member Author

rofinn commented Jun 1, 2022

That's what I thought, but @oxinabox said that yanking releases is typically only done for security or compat issues. Honestly, yanking releases appears to be an undocumented black art that I'm happy to avoid :)

@omus
Copy link
Collaborator

omus commented Jun 2, 2022

That's what I thought, but @oxinabox said that yanking releases is typically only done for security or compat issues. Honestly, yanking releases appears to be an undocumented black art that I'm happy to avoid :)

Definitely could be documented better. As the 1.7.0 release is still available it could still be used and break our semver requirements. I can yank 1.7.0 if that sounds good to you. In the future I suggest using yanking for this kind of rollback.

@oxinabox
Copy link
Member

oxinabox commented Jun 6, 2022

As the 1.7.0 release is still available it could still be used and break our semver requirements.

No more or less than any other release that is not the final patch release.
It's fine to yank it, but that exact same logic can be used to yank every patch release but the last.
Which, I have argued, should actually be the behavior of Pkg by default.
Namely that, post v1.0.0, only the last patch release should in installable unless some override flag is 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