If you have a package where a lot of people are still using a legacy version of it you might want to keep pushing (security-)fixes to that "branch".
Let's say the "latest" version of your package is "5.4.0", but there is as significant amount of people still using "4.7.4" – the last version you released before doing "5.0.0".
You found a critical bug in "5.4.0" and push it as out as "5.4.1", but it applies to "4.7.4" as well and so you want to do "4.7.5".
Assuming you have semantic-release already set up, you can follow these steps to get that "4.7.5" legacy support release out.
- Go to the relevant commit:
git checkout v4.7.4
- Create a new branch from it:
git checkout -b 4.x
(You can choose any branch name, just make sure to use the same in step 3) - Add
"branch": "4.x"
to yourpackage.json
's "release" field - Create a new "legacy" dist-tag:
npm dist-tag add <your-package>@4.7.4 legacy
(You can choose any tag name, except for "latest", just make sure to use the same in step 5) - Add
"tag": "legacy"
to your'package.json
's "publishConfig" field - Commit this
- Commit/cherry-pick the fix
- Push the "4.x" branch to GitHub
From now on you can keep the 4.x branch to push future fixes as well.
I agree, this should be part of the official documentation. Also, once the tag is set on the 4.7.4 release, you don't need to modify anything for it to be moved to 4.7.5? How is that handled?