Fix the `next-release` workflow in CircleCI - it's publishing old version numbers

[MantisClone]

Problem

The next-release workflow in CircleCI started releasing incorrect version numbers, based on old tags.

For example, it released @requestnetwork/advanced-logic@0.27.1-next.709

History

@MantisClone replaced several old lightweight tags with annotated tags in an attempt to fix the CHANGELOG.md files generated by lerna publish --conventional-commits.

• For force push output, see comment.
• For script used to replace lightweight tags with annotated tags, see https://github.com/RequestNetwork/release-tools/pull/5

We subsequently merged the #1435 hoping it would create new -next releases based on the latest 0.48.0 release tags. Unfortunately, this didn't work.

Then @MantisClone wrote and executed https://github.com/RequestNetwork/release-tools/pull/6, a script that backdated taggerdate of the annotated tags to Dec 4, 2020 based on the theory that lerna was getting confused by the out-of-order taggerdate. Unfortunately, this also didn't work.

@MantisClone also noticed that he forgot to backdate the taggerdate for the ethereum-storage tag due to a typo in the script, so he fixed the typo and re-ran the script. https://github.com/RequestNetwork/release-tools/pull/7

Then @MantisClone manually released a custom -next release - to unblock Request Finance in upgrading portal.

Then @MantisClone theorized that the root cause was because we "squash" merge our release branches, thus changing the commit hash and orphaning the tags applied by lerna publish --conventional-commits. So he tried revamping the release process in https://github.com/RequestNetwork/release-tools/pull/8 to do a regular merge instead of a squash merge. He used this new process to release 0.49.0. Unfortunately, even this did not fix the root cause. The next-release workflow still produced packages with old version numbers.

Finally, the root cause was found.

Root Cause

The next-release workflow published packages with old version numbers because lerna publish --canary uses git describe --first-parent to determine the previous annotated tag. --first-parent means that only tags originating from the master branch are considered, not tags originating from a merged branch. Since we've always applied annotated tags on branches, none of the annotated tags originate from master - EXCEPT FOR THE ONES @MantisClone WENT BACK AND MANUALLY CREATED!

Solution

1. Disable the --first-parent flag by passing --include-merged-commits when calling lerna publish in the next-release workflow.
2. Delete the annotated tags that @MantisClone created.

@MantisClone implemented solution (1) in #1440, but closed it and chose solution (2) instead.

Cleanup

@MantisClone cleaned up the release process in https://github.com/RequestNetwork/release-tools/pull/9