Note: Check out the entire supplemental source code for this blog series.
After releasing a new major version of our public library, we may still need to continue to push new bug fixes or other changes to older versions of the library. This will be easy to do using semantic-release and maintenance branches.
Let’s suppose that our library was on version v1.1.1. Next, we do a major release with a breaking change to bump our library to v2.0.0. With semantic-release, we can still push a new feature or fix to v1 of our library by creating a 1.x branch and opening a pull request against it.
In order to make this work there are a few things we should set up. First, we’ll need to create a 1.x branch:
git checkout -b 1.x
git reset --hard v1.1.1
git push -u origin 1.x
Next, we’ll have to add maintenance branch support to semantic-release by modifying our .releaserc.js config file:
./.releaserc.js
...
branches: [
'main',
'+([0-9]).x'
],
...
Note that semantic-release uses micromatch notation to match branches.
Also, we will need to tell our Release workflow to run on pushes to maintenance branches:
./.github/workflows/release.yml
...
on:
push:
branches:
- 'main'
- '[0-9]+.x'
...
Finally, we should protect our 1.x branch by enabling branch protection for it. One trick we can use is to specify * for the branch name pattern. This is a wildcard, but it won’t match /. So this will protect all our branches without a /. This can be very useful, because we can always open pull requests under topic branches such as topic/new-feature, or topic/bug-fix and they won’t be protected.
Now, when we merge a pull request into our new 1.x branch, semantic release will automatically deploy v1.2.0 or v1.1.2 (depending on if it’s a feat or fix, respectively).
Next, we’ll look at how to setup pre-releases and nightly releases with semantic-release and github actions.