REL: drop overly protective version upper limits for hard dependencies #3721
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.
PR Summary
Fix #3712
replaces #3713
Rationale:
I changed my mind about protective version capping after reading this blog post
https://iscinumpy.dev/post/bound-version-constraints/
Essentially, the reason why we're currently capping matplotlib (<3.6) is that we're used to seeing breaking changes in with every matplotlib minor release,
occasionally nasty ones (like the time matplotlib broke yt by erroring on colliding colormap names, see for instance #3165), but there was always the possibility to fix these problems on the user side by downgrading matplotlib.
The problem with that approach is that by setting upper limits in advance, we just make users unable to use future versions of our dependencies, even when they would probably be fine, and there is no easy workaround on the user side there.
Given that our release cadence is de facto slower than matplotlib's, it doesn't seem like a good long term strategy.
Note that I'm keeping some hard caps:
For reference, we've been having (and occasionally bumping) an upper limit for matplotlib since #3150