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

What determines which PRs should go in a milestone?#1706

AnsweredbyByron
EliahKagan asked this question inQ&A
Discussion options

I've noticed that a few pull requests that I would have expected to be labeled with thev3.1.38 milestone are not.#1700,#1659, and#1701 all make changes inside thegit module, yet are not so labeled.

On the other hand, I've realized I'm really not sure that is the criterion! There are some other PRs that do not make changes in thegit module thatare labeled with that milestone, including#1689 and#1703 which I don't think change any files that go on PyPI at all (not evenREADME.md).

As I understand it, in addition to not affecting what gets packaged, the milestone labeling also is not required for a PR to be listed in the automatically generated portion of the release notes that lists PRs. So if I understand correctly, the matter of what gets a milestone label is super low-stakes. Nonetheless I am curious how this is determined.

You must be logged in to vote

Thanks for bringing up the question which reveals a problem: by now, release notes are generated and that picks up all PRs automatically. Previously, that feature didn't exist which is why I manually assigned PRs and issues to milestones… unless I forgot.

Any inconsistency is due to me forgetting it 😁.

Thus I think the milestone concept can be completely removed for the maintenance mode this project is in, to rely on auto-generated release messages in GitHub. This means, the link in thechanges.rst file would then be pointing to the release page itself, which can also be predicted as the tag name will be known.

If you'd like, you could open a PR with the documentation updates in the READM…

Replies: 1 comment 1 reply

Comment options

Thanks for bringing up the question which reveals a problem: by now, release notes are generated and that picks up all PRs automatically. Previously, that feature didn't exist which is why I manually assigned PRs and issues to milestones… unless I forgot.

Any inconsistency is due to me forgetting it 😁.

Thus I think the milestone concept can be completely removed for the maintenance mode this project is in, to rely on auto-generated release messages in GitHub. This means, the link in thechanges.rst file would then be pointing to the release page itself, which can also be predicted as the tag name will be known.

If you'd like, you could open a PR with the documentation updates in the README to define the new workflow, which I welcome as it's less laborious :).

You must be logged in to vote
1 reply
@EliahKagan
Comment options

EliahKaganOct 13, 2023
Collaborator Author

I have done this in#1707.

Answer selected byEliahKagan
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@EliahKagan@Byron
[8]ページ先頭
©2009-2025 Movatter.jp