Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Versioning directives policy#24161

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

story645
Copy link
Member

Added policy to coding guidelines and PR guidelines based on discussion in#23506, samples of the directives are at#24160

- [ ] New features are documented, with examples if plot related.
- [ ] New features have an entry in `doc/users/next_whats_new/` (follow instructions in README.rst there).
- [ ] API changes documented in `doc/api/next_api_changes/` (follow instructions in README.rst there).
- [ ] New plotting related features are documented with examples.
Copy link
Member

Choose a reason for hiding this comment

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

This misses now a general statement "New features are documented".

Copy link
MemberAuthor

@story645story645Oct 15, 2022
edited
Loading

Choose a reason for hiding this comment

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

Yeah cause I wasn't sure how they're documented besides docstrings, what's new, and examples?

@tacaswell
Copy link
Member

Responding to a question from@jklymak in#24160, I think we should be on the liberal side of adding these notes. It seems like we get ~ a bug report per month of "Why doesn't this documented feature work?!" to which the answer is "it was added in a newer version than you have installed. If the docs clearly say what version the feature was added in hopefully we can reduce that user frustration.

That said, having the version switcher on the docs does help make it easier to see the docs for the version you have installed.

If we get to a point where we have so many of these where it is distracting, my knee-jerk thought is to start removing 3-4 version of markers to keep the total number down...

timhoffm reacted with thumbs up emoji

@jklymak
Copy link
Member

That's fine with me. Otoh we need to be explicit about what is new if we do this for api changes.

story645 reacted with thumbs up emoji

@tacaswelltacaswell added this to thev3.7.0 milestoneOct 15, 2022
@story645story645force-pushed theversioning-directives-policy branch 2 times, most recently from27d63c1 to7e79c01CompareOctober 16, 2022 01:30
@oscargus
Copy link
Member

Should we also have some removal policy? I guess the documents may be a bit unreadable if version info for every change since 2004 would be in there...

@timhoffm
Copy link
Member

I'd go with Tom's suggestion. We should start thinking of removal, when it get's too distracting. But that can be decided when we're there. Guessing up-front is not necessary.

@oscargus
Copy link
Member

Agreed. Missed that comment though...

@story645story645force-pushed theversioning-directives-policy branch from7e79c01 toa883398CompareOctober 20, 2022 19:52
@timhoffm
Copy link
Member

Since this is not only documentation but sets a policy, I'd like to have a second review.

story645 reacted with thumbs up emoji

@story645
Copy link
MemberAuthor

story645 commentedOct 21, 2022
edited
Loading

@timhoffm question from#24160 - do we want to explicitly state whether the directives should be blank or give some context or leave that as a case by case?
ETA: Also thanks!

@timhoffm
Copy link
Member

@story645 I've replied here:#24160 (comment)

@story645
Copy link
MemberAuthor

Um should there be a placeholder letter instead of 3 too or not worth it for now?

… some other wordingCoding guide: documented directive policyCo-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>Co-authored-by: melissawm <melissawm@gmail.com>Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
@story645story645force-pushed theversioning-directives-policy branch fromd3d3fd6 to8454605CompareOctober 23, 2022 19:45
@timhoffm
Copy link
Member

Um should there be a placeholder letter instead of 3 too or not worth it for now?

This is clear enough. Let's not overthink this. (IMHO people would understand all ofX.Y,3.N,3.6)

@story645
Copy link
MemberAuthor

story645 commentedOct 24, 2022
edited
Loading

IMHO people would understand all of X.Y, 3.N, 3.6

So leaving it here as 3.N to be consistent but b/f#23941 we were using X.Y. as minor.patch and now I'm tempted to make a follow up PR that just spells these things out asmajor.minor.patch throughout the dev docs

@timhoffm
Copy link
Member

I'm not in favor ofmajor.minor.patch because that is quite verbose and it's less clear that these are variables.

If anything I have a slight preference for the concrete example.. versionadded:: 3.6. - People are able to generalize from that and won't copy literally. Generalizing seems a bit simpler that guessing what a variable should be. But as said

Let's not overthink this. (IMHO people would understand all ofX.Y,3.N,3.6)

@QuLogicQuLogic merged commit42fdbea intomatplotlib:mainOct 26, 2022
@story645story645 deleted the versioning-directives-policy branchOctober 26, 2022 06:03
@story645story645 linked an issueOct 27, 2022 that may beclosed by this pull request
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@QuLogicQuLogicQuLogic approved these changes

@timhoffmtimhoffmtimhoffm approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
v3.7.0
Development

Successfully merging this pull request may close these issues.

[Doc]: add sphinx versioning directives
6 participants
@story645@tacaswell@jklymak@oscargus@timhoffm@QuLogic

[8]ページ先頭

©2009-2025 Movatter.jp