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

Freeze IntervalArithmetic v0.20 in /docs #143

Merged
merged 1 commit into from
Oct 7, 2023
Merged

Conversation

schillic
Copy link
Member

@schillic schillic commented Oct 7, 2023

This is an attempt to prevent CompatHelper from bumping the version as in #141. IntervalArithmetic v0.21 would require changes to the docstrings, so this version should be mutually exclusive with v0.20. But currently, v0.21 is incompatible with many dependencies, so it cannot be used.

@lucaferranti
Copy link
Member

from Pkg.jl documentation https://pkgdocs.julialang.org/v1/compatibility/

Caret specifiers are the default and hence 1.2.3 == ^1.2.3.

so I am not sure this is doing what you think, since it's not changing anything

I am not sure if there's a way to tell compat-helper to black list some packages, I'll ask on slack

@lucaferranti
Copy link
Member

I think it's not possible atm: JuliaRegistries/CompatHelper.jl#404

@schillic
Copy link
Member Author

schillic commented Oct 7, 2023

I know, but it seems that for CompatHelper, these things differ. In your linked issue, the developer even says that. So let us just try. I will merge and tomorrow we see if there is a new PR.

@schillic schillic merged commit c586beb into master Oct 7, 2023
5 checks passed
@schillic schillic deleted the schillic/compat branch October 7, 2023 14:16
@lucaferranti
Copy link
Member

yes, but in the linked issue, the suggestion is

[compat]
Foo = ">= 1.2.3"

which is unbounded above, that is every version in the range [1.2.3, Inf] is alrady compatible, which is why CompatHelper does not open the PR, because every new version is already automatically compatible

@schillic
Copy link
Member Author

schillic commented Oct 7, 2023

There is another issue where the bound was ~ and it was not supposed to update. It was marked as a bug, so this is indeed the intended behavior. I guess the same is true for ^.

Patience... :)

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.

2 participants