There are currently a few issues with the changelog generator:
No more than 250 commits are considered due to GitHub’s “compare commits” API being used. This should be replaced by usage of an API that is able to iterate over long commit ranges and require an authentication token, for the user running the script, to allow paginating through all the commits.
Because of how RN’s release process works, we cannot simply use git’s history to inform the generator on what changes should be included in the changelog.
The reason being that cherry-picked commits are new changes, as far as git is concerned, and may thus be picked up again in subsequent releases. (For a reproduction of this issue, see this example. The v1 commit is not expected to show up in this diff, as it was picked for v1, yet there it is.)
After having slept on it for a few days, I think the best way to solve this is to:
Use the “differential revision” that FB’s infrastructure adds to each commit to find the SHA of the commit in master, then;
check if that SHA already exists in the changelog, in which case it is skipped, or otherwise;
add the entry to the changelog with the commit SHA as it exists in master, rather than the stable branch.
Finally, when invoking the generator, compare the current 0.x-stable branch against the commit from which the previous0.x-stable branch was forked off of master–as not all commits in master since then will have been included in the previous release.
TL;DR Use the master commit ref as canonical and check for its existence in the changelog to decide wether or not to include it.
Related to this card.
There are currently a few issues with the changelog generator:
No more than 250 commits are considered due to GitHub’s “compare commits” API being used. This should be replaced by usage of an API that is able to iterate over long commit ranges and require an authentication token, for the user running the script, to allow paginating through all the commits.
Because of how RN’s release process works, we cannot simply use git’s history to inform the generator on what changes should be included in the changelog.
The reason being that cherry-picked commits are new changes, as far as git is concerned, and may thus be picked up again in subsequent releases. (For a reproduction of this issue, see this example. The
v1
commit is not expected to show up in this diff, as it was picked forv1
, yet there it is.)After having slept on it for a few days, I think the best way to solve this is to:
master
, then;master
, rather than the stable branch.0.x-stable
branch against the commit from which the previous0.x-stable
branch was forked off ofmaster
–as not all commits inmaster
since then will have been included in the previous release.TL;DR Use the
master
commit ref as canonical and check for its existence in the changelog to decide wether or not to include it.