What determines which PRs should go in a milestone?

[EliahKagan]

I've noticed that a few pull requests that I would have expected to be labeled with the v3.1.38 milestone are not. #1700, #1659, and #1701 all make changes inside the git 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 the git module that are labeled with that milestone, including #1689 and #1703 which I don't think change any files that go on PyPI at all (not even README.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.

[Byron]

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 the changes.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 :).

[EliahKagan]

I have done this in #1707.