fix: include merged tags when determining the previous release #1440
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Towards #1442
Problem
The
next-releaseworkflow in CircleCI releases a-nextpackage in NPM. It determines the version number based on the previous annotated, tagged commit originating from themasterbranch. It doesn't consider tags that were merged from other branches.In #1381 (comment), I force-pushed several annotated tags in an attempt to fix the auto-generated CHANGELOG.md files. Before this, there were zero annotated, tagged commits originating from the
masterbranch so thenext-releaseworkflow would fallback to counting commits from the beginning fo time. This is why the-nextreleases end with a number instead of a commit hash.The reason there was zero annotated, tagged commits originating from the
masterbranch is that we've always used squash merge to merge PRs intomaster. squash merge changes the commit hash, thus orphaning the tags produced bylerna publish.Proposed Solution
--include-merged-commitsoption in thenext-releaseworkflow. We could adopt the release process in https://github.com/RequestNetwork/release-tools/pull/8 which useslerna publishon areleasebranch and thenmerges(notsquash merge) the tagged commits to master. The-nextreleases going forward would haveshortSHApostfixes instead ofrefCountpostfixes. This requires us to enablemergeon themasterbranch which I don't love - because it runs the risk that non-conventional commits are merged to themasterbranch.Alternative Solution
masterbranch. We could still adopt the new release process in https://github.com/RequestNetwork/release-tools/pull/8 except continue using squash merge for thereleasebranch. The-nextreleases going forward would still have therefCountpostfixes, and we wouldn't have to enablemergeon themasterbranch. I don't love this option either because it eliminates the possibility of bumping the version on only changed packages instead of force-publishing all packages every time.