Skip to content

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

Closed
eric-wieser opened this issue Jun 4, 2019 · 11 comments
Closed

Assemble release notes at release time, not during development #13707

eric-wieser opened this issue Jun 4, 2019 · 11 comments

Comments

@eric-wieser
Copy link
Member

eric-wieser commented Jun 4, 2019

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:

  • They frequently create merge conflicts which are frustrating for everyone to rebase
  • If a PR does not make it into its intended release, the PR is unmergeable until someone gets around to moving the release notes
  • If a PR is scheduled for a future version that isn't the next release, there's no way to write the release notes at all until it becomes the "current" release
  • Backported PRs requires manual reassembly of 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:

Some advantages of what we already do:

  • It's typically possible to blame the release notes to find the patch that introduced the change
  • You can read the master release notes in a single place. We could probably achieve this in the dev-docs anyway though.
@eric-wieser
Copy link
Member Author

@tacaswell: would be great to hear matplotlib's perspective on this

@rgommers
Copy link
Member

rgommers commented Jun 4, 2019

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:

  • Con: it's still some manual work (not much, but probably more than blurb/towncrier)
  • Pro: there's no tool/syntax to learn, so you can just ask any contributor "can you please edit this wiki page" and they know what to do.

@seberg
Copy link
Member

seberg commented Jun 5, 2019

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).

@mattip
Copy link
Member

mattip commented Jun 27, 2019

Matplotlib has a PR to move to towncrier matplotlib/matplotlib#14589.

@seberg
Copy link
Member

seberg commented Jun 27, 2019

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.

@anntzer
Copy link
Contributor

anntzer commented Jul 16, 2019

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).

@seberg
Copy link
Member

seberg commented Jul 16, 2019

@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 python -m towncrier.check, but that seems not the correct incarnation?). Although... assuming we are right and towncrier does not support/check for towncrier.toml yet, we could fix that upstream I suppose.

@anntzer
Copy link
Contributor

anntzer commented Jul 16, 2019

I haven't checked in depth that the PR on matplotlib's side actually works :p just pointing out the discussion.

@tacaswell
Copy link
Contributor

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?

@rgommers
Copy link
Member

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.

@seberg
Copy link
Member

seberg commented Sep 22, 2019

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.

@seberg seberg closed this as completed Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants