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-release
workflow in CircleCI releases a-next
package in NPM. It determines the version number based on the previous annotated, tagged commit originating from themaster
branch. 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
master
branch so thenext-release
workflow would fallback to counting commits from the beginning fo time. This is why the-next
releases end with a number instead of a commit hash.The reason there was zero annotated, tagged commits originating from the
master
branch 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-commits
option in thenext-release
workflow. We could adopt the release process in https://github.com/RequestNetwork/release-tools/pull/8 which useslerna publish
on arelease
branch and thenmerges
(notsquash merge
) the tagged commits to master. The-next
releases going forward would haveshortSHA
postfixes instead ofrefCount
postfixes. This requires us to enablemerge
on themaster
branch which I don't love - because it runs the risk that non-conventional commits are merged to themaster
branch.Alternative Solution
master
branch. We could still adopt the new release process in https://github.com/RequestNetwork/release-tools/pull/8 except continue using squash merge for therelease
branch. The-next
releases going forward would still have therefCount
postfixes, and we wouldn't have to enablemerge
on themaster
branch. 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.