Tested it myself on Linux, works there as-well. Merging.

Release notes?

I dunno if we should have a decision on this, but i.m.o. it is much easier to simply compile the release notes when we decide to do a release. Adding notes to a change like this causes the pull to become like 3 times larger (or 10, in this case) and basically causes a merge conflict between all pull requests (since they will want to be editing the same file).

It seems most other packages (e.g. numpy) seem to work this way as well.

It seems most other packages (e.g. numpy) seem to work this way as well.

Not in my experience. They have a release notes file for each release separately, including the upcoming one, which is updated in a rolling way. I once made a PR and was asked to write something in that file (earlier version, of course).

but i.m.o. it is much easier to simply compile the release notes when we decide to do a release

I think it's much harder since the person who compiles the PRs either does not know exactly what the PR is about (or which side issues it also fixes, which is not that uncommon, ahem) simply because somebody else did it, or it was long ago and has a hard time remembering. What takes maybe 2 minutes per PR then takes easily double the time.

Adding notes to a change like this causes the pull to become like 3 times larger (or 10, in this case)

How? It's basically 1-3 additional lines in some document. If that is too much, I don't know what more to say. And why is the relative measure against the number of lines changed in the PR relevant at all?

causes a merge conflict between all pull requests (since they will want to be editing the same file).

Which should be really easy to resolve.

Not in my experience. They have a release notes file for each release separately, including the upcoming one, which is updated in a rolling way. I once made a PR and was asked to write something in that file (earlier version, of course).

I had a look at all closed pull request on the first page of numpy, about 25 of them, and none of them wrote anything to the upcoming changes file. So it is at least rather infrequent. It seems they only do it for larger changes (breaking or new feature).

I think it's much harder since the person who compiles the PRs either does not know exactly what the PR is about (or which side issues it also fixes, which is not that uncommon, ahem) simply because somebody else did it, or it was long ago and has a hard time remembering. What takes maybe 2 minutes per PR then takes easily double the time.

The problem is that there is no "somebody else". If you look at the closed pull requests, at least 80% of small changes (i.e. non feature branches) are done by me, and I can keep relatively good track of these things, especially given our short release cycle.

Adding more obstacles would, imo, only be worth it if at some point someone other than me started doing small changes at a scale where it is noticeable. Otherwise it is simply going to be yet another obstacle stopping people from contributing.

If we decide to keep updating the release notes in each PR, even minor bug fixes, then we need to improve the workflow for that, specifically get rid of the pull requests file and handle that somehow else, possibly with some sphinx plugin, or by simply ignoring what pull request changed what and only writing the changes (like numpy).

Added a new PR (#510) which addresses the last point.

I had a look at all closed pull request on the first page of numpy, about 25 of them, and none of them wrote anything to the upcoming changes file. So it is at least rather infrequent. It seems they only do it for larger changes (breaking or new feature).

That's quite possible. I was implementing a corner case in np.broadcast so that counts as a new feature probably (changed behavior from error to something reasonable). I certainly agree that putting everything in the release notes is not really necessary, especially bugfixes that address internal things or rare corner cases or anything else a typical user won't notice.

The problem is that there is no "somebody else". If you look at the closed pull requests, at least 80% of small changes (i.e. non feature branches) are done by me, and I can keep relatively good track of these things, especially given our short release cycle.

But that would imply that it's always going to be you who compiles the PRs (at least the small ones). If that's okay for you, fine :-).
Seriously, there is no reason to do exactly what we are doing now, but at least we want to list all changes that a typical user would be able to or should notice. For me, this implies

• major bugfixes
• API changes
• new features
• performance improvements

What we don't need to mention are basically minor fixes and test-related stuff (like this one 😛).

Agree with the above, and now that we can update the notes by editing only the notes file it should be reasonably simple to do, even possible from GitHub.

Okay great! But the above reasoning puts #509 on the list (API change) 😉

Fixed in 675c187