Support backport releases #37
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Every so often we may want to copy a fix from the latest version of a package to a previously-released version. This type of release is called a backport. Outside of any automation, when we want to apply a backport, we will switch to the Git tag that corresponds to the previous release, cut a new branch that corresponds to that particular version line (e.g. `1.x`), apply the fixes, push a pull request for those fixes, and merge them into that branch. When we want to *release* these changes, we will make another branch, bump versions and update changelogs, push that branch as a pull request, merge it in, and then finally publish NPM packages and create the GitHub release. So we want to automate this workflow, but one question that comes to mind is, what version do we assign to such a release? Typically, when we issue a new release that *isn't* a backport, we will bump the first part of the version string (e.g. if the current version is "1.0.0", we will assign "2.0.0" as the new version string). Since backports are applied to previous releases, they are assigned a new version that is a modification of the version they are fixing. So when we name a backport release, we will take the base version and bump its *second* part (e.g. if the existing version is "1.0.0", the backport release will be called "1.1.0"). With that in mind, this commit adds a `--backport` option to the tool. When you specify this, it will assume that you are already on a version line branch (e.g. `1.x`) and that the current version of the primary package (the root package for a monorepo, the sole package for a polyrepo package) is the one that you want to fix. It will then use *this* version of the package (instead of the latest released version) to apply the changes. In the case of a monorepo, it will determine which workspace packages have changed since the Git tag that corresponds to the current version of the primary package (again, not the latest tag) and use this to populate the release spec. It will then bump the second part of the primary package version (as opposed to the first) and proceed as usual.
Gudahtt
approved these changes
Oct 5, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Every so often we may want to copy a fix from the latest version of a package to a previously-released version. This type of release is called a backport.
Outside of any automation, when we want to apply a backport, we will switch to the Git tag that corresponds to the previous release, cut a new branch that corresponds to that particular version line (e.g.
1.x), apply the fixes, push a pull request for those fixes, and merge them into that branch. When we want to release these changes, we will make another branch, bump versions and update changelogs, push that branch as a pull request, merge it in, and then finally publish NPM packages and create the GitHub release.So we want to automate this workflow, but one question that comes to mind is, what version do we assign to such a release? Typically, when we issue a new release that isn't a backport, we will bump the first part of the version string (e.g. if the current version is "1.0.0", we will assign "2.0.0" as the new version string). Since backports are applied to previous releases, they are assigned a new version that is a modification of the version they are fixing. So when we name a backport release, we will take the base version and bump its second part (e.g. if the existing version is "1.0.0", the backport release will be called "1.1.0").
With that in mind, this commit adds a
--backportoption to the tool. When you specify this, it will assume that you are already on a version line branch (e.g.1.x) and that the current version of the primary package (the root package for a monorepo, the sole package for a polyrepo package) is the one that you want to fix. It will then use this version of the package (instead of the latest released version) to apply the changes. In the case of a monorepo, it will determine which workspace packages have changed since the Git tag that corresponds to the current version of the primary package (again, not the latest tag) and use this to populate the release spec. It will then bump the second part of the primary package version (as opposed to the first) and proceed as usual.Fixes #32.