-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
Assemble release notes at release time, not during development #13707
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@tacaswell: would be great to hear matplotlib's perspective on this |
SciPy did what NumPy does, considered the same problem, and switched to just putting release notes in a wiki page at merge time. It solves the pain points, the tradeoffs are:
|
Just to note, we discussed it a bit today, and while nobody seemed to have a huge preference, I think the consensus was to try the wiki based approach while probably editing the initial PRs post/comment to include a draft of the release notes which can be copied over easily. EDIT: The reason for the PR notes, is that you can only place it in the wiki once it is actually merged (and it is probably good to have it there as well in any case). |
Matplotlib has a PR to move to towncrier matplotlib/matplotlib#14589. |
IIRC there was a lot of support for that as well on the mailing list. Lets bring it up tomorrow and unless Chuck feels differently, probably go for it for 1.18. |
I noted that the dev meeting notes mention the fact that this will require using pyproject.toml. Note that this is not the case, and indeed, for matplotlib, we are putting the config in towncrier.toml (requires a flag when invoking towncrier; see discussion in matplotlib/matplotlib#14589). |
@anntzer I would maybe prefer that solution, but I have not seen that towncrier actually added that functionality as of now (it does exist for |
I haven't checked in depth that the PR on matplotlib's side actually works :p just pointing out the discussion. |
Matplotlib moved from PRs editing one file to one file per change for exactly the reasons in the OP (mostly the merge conflicts). However, the manual re-combination is surprisingly time consuming (hence why we are looking at towncrier). With the wiki approach do you copy the wiki page into the main docs at release time? |
Yes indeed. The process is as simple as asking on any PR that needs release notes to add an entry to (e.g. for 1.3.) https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.3.0, and then after branching copy the whole thing into a single release notes file. No machinery, no conflicts. It's quite nice. |
I will close this, there may still be some bumps about towncrier, but it should be working fine (although with the current development version). And this was about the general thing, not specifics. |
This has been brought up before (#8603), but I think it's time to create a tracking issue.
We have a number of problems with how we currently manage release notes:
All of these would be fixed by a "one file per section" approach to release notes, which matches what matplotlib and cpython do.
Some options:
cat
or similar?) like matplotlib doesblurb
, which is what cpython doestowncrier
, which has been suggested in the pastSome advantages of what we already do:
The text was updated successfully, but these errors were encountered: