More accurate release notes for backport releases

[christopher-dG]

Suppose I make the following releases, in order: 1.0.0, 2.0.0, 1.0.1

• Issues/PRs included in release notes for 1.0.0 are from beginning of time -> 1.0.0.
• For 2.0.0, they're from 1.0.0 to 2.0.0
• For 1.0.1, they're from 1.0.0 to 1.0.1 because 1.0.0 is the previous version according to SemVer, not 2.0.0. But usually, most of the issues/PRs included in the release notes are actually to do version 2.0.0, and thus not relevant to 1.0.1. The generator collects stuff solely based on close/merge time.

An idea: Most backport releases are not made on the main branch, and we can use that to help prune the issues/PRs.

• Get the the commit being registered from the registry PR.
• Figure out what branch that commit is on. For normal releases, this is basically always the default branch, but for backports, often it's release-A.B or similar and not on the default branch.
• Ignore all pull requests that were not merged into this branch.

Pruning issues is harder, since they don't have a base branch of their own. But they're often associated with (closed by) PRs, and we could select only the issues that were closed by a PR that was merged into the release branch. But errors in that approach result in lost information rather than extra information, and it's a lot easier to remove stuff manually than to add it in manually. And ultimately, that approach gets the same or less as just taking all issues from the previous chronological release.

So maybe the best bet is to take only PRs that were merged into the release branch since the previous SemVer release, and take all issues that were closed since the last chronological release.

[c42f]

Great summary. I've hit this a couple of times in the opposite order:

1.0.0 -> 1.0.1 -> 2.0.0

where 1.0.1 is a tiny release made on a branch, but gets attributed most of what 2.0.0 should include. Then the 2.0.0 release notes include hardly anything.

[maleadt]

Is there a workaround for this? On multiple occasions (e.g. see above) I've had users confused about a feature that Tagbot had put in the release notes of a backport release while it's only available on master, not even in any release.

[oxinabox]

It would be nice if in doubt tagbot would put nothing user viable.
(Could generate the full text and hide in a markdown comment so if package mainainer wants to use some of it to write the release notes they can edit it in)

I think detecting the in doubt cases is probably easier?

[fonsp]

This will still mean that issues and PRs get 'swallowed' by a backport release (1.0.1 in the example) and won't show up in the release that actually contains these fixes, right?