Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Make deprecations versions explicit #17242

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 4 commits into from
Apr 30, 2020
Merged

Make deprecations versions explicit #17242

merged 4 commits into from
Apr 30, 2020

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Apr 25, 2020 •
edited
Loading

PR Summary

Messages without %(since)s and %(removal)s will be ambiguous as to when they were deprecated and when they will be removed.

Also clean up extra 'in's in the messages as %(removal)s will add the correct preposition.

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • [N/A] New features are documented, with examples if plot related
  • [N/A] Documentation is sphinx and numpydoc compliant
  • [N/A] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • [N/A] Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

QuLogic added 3 commits April 25, 2020 00:13
@QuLogic
Make enter_notify_event deprecation more explicit.
0365e18 
Since this did not previously note a removal version, I bumped it to 3.5
(assuming this is merged for 3.3.)
@QuLogic
Remove extra 'in' in deprecation messages.
427f0f9 
The %(removal)s substition already includes 'in' or whatever prefix is
necessary.
@QuLogic
Add explicit versions to deprecation messages.
b1f4b8f 
Messages without `%(since)s` and `%(removal)s` will be ambiguous as to
when the were deprecated and when they will be removed.
@QuLogic QuLogic added this to the v3.3.0 milestone Apr 25, 2020
@anntzer
Copy link
Contributor

anntzer commented Apr 25, 2020

I wonder whether we should just make the deprecation machinery check the contents of message and, if it doesn't contain %(since)s or %(removal)s, append something like "This deprecation started in mpl %(since)s and will elapse %(removal)s"?

@QuLogic
Copy link
Member Author

QuLogic commented Apr 27, 2020

I was thinking about that, but it seems like one or two intentionally left it out; maybe we should only do that if pending=False?

@QuLogic QuLogic added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Apr 27, 2020
@QuLogic
Copy link
Member Author

QuLogic commented Apr 27, 2020

Marking as RC, as we shouldn't put out a release without the right numbers, whatever way we decide to do it.

@anntzer
Copy link
Contributor

anntzer commented Apr 27, 2020

pending=False explicitly disallows having a scheduled removal, so sure.

tacaswell
tacaswell reviewed Apr 29, 2020
View reviewed changes
tacaswell
tacaswell approved these changes Apr 29, 2020
View reviewed changes
Copy link
Member

@tacaswell tacaswell left a comment

Choose a reason for hiding this comment

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

This can go in as-is or we can wait for the validation.

@QuLogic
Copy link
Member Author

QuLogic commented Apr 29, 2020

I bumped the dates for the above to_rgba_array and #16417.

@tacaswell
Copy link
Member

Going to make an executive decision and merge this.

@tacaswell tacaswell merged commit 9575c76 into matplotlib:master Apr 30, 2020
@QuLogic QuLogic deleted the explicit-deprecations branch April 30, 2020 19:05
@QuLogic QuLogic mentioned this pull request May 1, 2020
Merged
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tacaswell tacaswell tacaswell approved these changes

Assignees
No one assigned
Labels
Maintenance Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Milestone
v3.3.0
Development

Successfully merging this pull request may close these issues.
3 participants
@QuLogic @anntzer @tacaswell