You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
it('bumps the backport part of the root package and updates the versions of the specified packages according to the release spec if --backport is provided',async()=>{
it("updates each of the specified packages' changelogs by adding a new section which lists all commits concerning the package over the entire history of the repo",async()=>{
0 commit comments