FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

sample versioning directives, empty + description by story645 · Pull Request #24160 · matplotlib/matplotlib · GitHub

Repository navigation

sample versioning directives, empty + description - #24160

Merged
timhoffm merged 1 commit into
matplotlib:mainfrom
story645:versioning-directives
Oct 25, 2022
Merged

timhoffm merged 1 commit into
matplotlib:mainfrom
story645:versioning-directives

Conversation

story645 commented Oct 14, 2022 •
edited
Loading

Copy link
Copy Markdown
Member

Based on discussion on call and in #23506, trying out some versioning directives. Policy at #24161

Haven't styled anything yet, tried w/o and w/ description cause wasn't sure what made more sense. I guess w/o is a pointer to go look up those release notes, but not sure how to document that. The issue is that these two are partially new things - polar errobars and more valid parameter values, rather than wholly new things.



story645 changed the title add versioning directives, including empty + description sample versioning directives, empty + description Oct 14, 2022

jklymak commented Oct 14, 2022

Copy link
Copy Markdown
Member

I guess we should have discussed the threshold for this. I naively thought just for new methods or classes. What do other libraries do?

Copy link
Copy Markdown
Member Author

Yeah I realized it was weird cause we use what's new for lots of what's changed and have almost no non-deprecation API changes

Copy link
Copy Markdown
Member

and have almost no non-deprecation API changes

Which is a good thing (API stability 👍). Additions/extensions are in "What's new". Almost all other changes should have deprecations.

Copy link
Copy Markdown
Member Author

Is there preference for the summary or blank version? If yes, should I document that in #24161? Also any styling preferences?

story645 force-pushed the versioning-directives branch from eb647ac to 802b89f Compare October 21, 2022 03:59

Copy link
Copy Markdown
Member

Is there preference for the summary or blank version? If yes, should I document that in #24161?

Whether a comment makes semse depends is case-by-case: If the whole thing (function/parameter/...) is new there is nothing more to say. If only part is new, like in the {}-style example, that should be documented. If you want to be very explicit, you can document that, but I would also be ok to not write that out in text but add one more example with such a summary.

story645 force-pushed the versioning-directives branch from 802b89f to cfa28b0 Compare October 23, 2022 20:17
Comment thread lib/matplotlib/axes/_axes.py Outdated
Comment thread lib/matplotlib/axes/_axes.py Outdated
Co-authored-by: melissawm <melissawm@gmail.com>

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
story645 force-pushed the versioning-directives branch from 434735a to 7c3b627 Compare October 25, 2022 01:22
timhoffm added this to the v3.7.0 milestone Oct 25, 2022
timhoffm merged commit 7f0c965 into matplotlib:main Oct 25, 2022
story645 deleted the versioning-directives branch October 25, 2022 15:25
story645 linked an issue Oct 27, 2022 that may be closed by this pull request
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Doc]: add sphinx versioning directives

3 participants


Back | FazBrowse Home | New Git URL