Release guidelines
In this document, 123 is a placeholder for the current release number, and 124 for the following release number.
Beta releases
Beta release
dev
branch: updateCHANGELOG.md
. Change theUnreleased
heading to123.0.0-beta.1
.dev
branch: update the user manual URL if necessary.- Create a
release/123.0
branch using thedev
branch. release/123.0
branch: update thepackage.json
version string to123.0.0-beta.1
. Runnpm install
to updatepackage-lock.json
.- Create a
v123.0.0-beta.1
tag using the release branch. - Test the release branch. Make any required fixes in the
dev
branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag. - Create packages from the release branch.
After beta release
dev
branch: updateCHANGELOG.md
. Create a newUnreleased
section.dev
branch: update the documentation website (guidelines). Create a new version123.0.0-beta.1
.
Additional beta release
This process should be followed if changes have to be made after the beta packages have already been published (or even provided to a limited number of users). If there are significant changes in dev
that should not be included in the beta release, follow the point release procedure instead (but adjust the version strings as required).
- Make the required fixes in
dev
. dev
branch: updateCHANGELOG.md
. Change theUnreleased
heading to123.0.0-beta.2
.dev
branch: update the user manual URL if necessary.- Merge the
dev
branch into therelease/123.0
branch. release/123.0
branch: update thepackage.json
version string to123.0.0-beta.2
. Runnpm install
to updatepackage-lock.json
.- Create a
v123.0.0-beta.2
tag using the release branch. - Test the release branch. Make any required fixes in the
dev
branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag. - Create packages from the release branch.
Stable releases
Final release
dev
branch: updateCHANGELOG.md
. Change theUnreleased
heading to123.0.0
.dev
branch: update the user manual URL if necessary.- Merge the
dev
branch into therelease/123.0
branch. release/123.0
branch: update thepackage.json
version string to123.0.0-rc.1
. Runnpm install
to updatepackage-lock.json
.- Create a
v123.0.0-rc.1
tag using the release branch. - Test the release branch. Make any required fixes in the
dev
branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag. release/123.0
branch: update thepackage.json
version string to123.0.0
. Runnpm install
to updatepackage-lock.json
.- Create a
v123.0.0
tag using the release branch. - Create packages from the release branch.
After final release
dev
branch: update thepackage.json
version string to124.0.0-dev
. Runnpm install
to updatepackage-lock.json
.dev
branch: updateCHANGELOG.md
. Create a newUnreleased
section.dev
branch: update the documentation website (guidelines). Create a new version123.0.0
.
Point release
This process should be followed if important bug fixes have to be released after the final release packages have already been published (or even provided to a limited number of users). If there are no changes in dev
that should not be included in the point release, follow the additional beta release procedure instead (but adjust the version strings as required).
- Make the required fixes in
dev
. Cherry-pick them into the release branch. dev
branch: updateCHANGELOG.md
. Move the cherry-picked changes from theUnreleased
section to a new123.0.1
section underUnreleased
.release/123.0
branch: updateCHANGELOG.md
. Copy only the123.0.1
section from the changelog in thedev
branch.release/123.0
branch: update thepackage.json
version string to123.0.1
. Runnpm install
to updatepackage-lock.json
.- Create a
v123.0.1
tag using the release branch. - Test the release branch. If an issue affects both
dev
and the release branch, fix it indev
and cherry-pick the changes into the release branch. If an issue is caused by changes indev
which are not included in the point release, make the minimal required changes in the release branch. Ideally, bump the version and create a new tag every time changes are made. If you don't want to bump the version, remember to destroy and recreate the latest tag. - Create packages from the release branch.
After point release
dev
branch: update the documentation website (guidelines). Replace version123.0.0
with123.0.1
.