Changelog automation does not work for new release branches

[williamhbaker]

When we create a new release branch, ideally the changelog would be automatically generated to include all commits from master except for ones which have previously been released. This is complicated, because previous releases will have included some of the commits from the master branch, but not all of them, so the challenge is to include only the commits from master which have not previously been released.

For example, consider the 2.0 and 2.1 branches off of master in the picture below:

The short horizontal gray lines represent commits - some of them were backported and released with 2.0, but not all of them. The changelog for the 2.1 release branch needs to include all of the commits since the most recent release branch diverged except for the ones which were backported, + any additional commits on the 2.1 release branch.

This may be tremendously simplified by just tagging releases off of the master branch in the future.

[williamhbaker]

We've discussed a potential strategy for handling this. One important thing is that there needs to be some sort of automation-friendly way to determine backports that exist on a release branch and on master. This could be achieved by enforcing that the PR has the exact same name as the PR that is being backported, using cherry-pick -x to store the original commit hash in the new commit message, etc. Then, an algorithm like the following could be used to determine the changelog for a release branch:

• list 1 is all of the changes between:
  • the commit on master that the previous release branch diverged on
  • the head of this release branch
• list 2 is all of the changes between:
  • the commit on master that the previous release branch diverged on
  • the most recent release-tagged commit of the previous release branch
• the changelog for this release branch is then list 2 subtracted from list 1

There may be edge cases where this process would not work well if things do not backport cleanly, like if a change on master is only partially backported to a release branch.

[lesam]

I would prefer matching up commits on the commit name (with squash merges, really the PR name).

If two PR's are named exactly the same, hopefully they do the same thing. If we mess up and name the same PR differently during the backport, it's not too terrible to accidentally include it a second time (though hopefully we would catch that when writing up the official release notes).