This page explains how to create a release of the Rollups Node by showing each step that should be performed, from updating the change log and testing the changes to announcing a release.
Before starting the release process, we must confirm all project dependencies have been updated for the new release.
All related tasks are described in the update-dependencies issue template.
On your local machine, make sure to pull the latest changes made to the main
branch.
Execute all end-to-end tests and whatever specific tests concerning the changes made at the release (let's use X.Y.Z
as the release version number).
If necessary, fix any issues with the team by following the normal development workflow.
Once all tests pass and the main
branch is up-to-date, proceed to the next step.
Update the CHANGELOG
Confirm the code changes listed under Unreleased
are accurate, and then:
- in the beginning of the file, replace the heading
Unreleased
with the version number of the new release, followed by the current date (YYYY-MM-DD
); - at the end of the file, create a link to the differences from the new release to the previous one;
- update the link to the differences related to the
Unreleased
changes.
Commit the changes, push them to the repository and create a corresponding pull request.
A sample commit may be found in the repository.
Once the pull request is approved, merge it and update your local copy of the main
branch.
Then, create a new tag for the release based on the main
branch as follows:
git tag -a vX.Y.Z
Make sure to add a message to the tag commit as follows:
Release X.Y.Z
Then, push the tag to th repository:
git push origin vX.Y.Z
Check if the CI actions associated with the release pass.
After that, pull the docker image generated by the CI to make sure it's been pushed to Docker hub as follows:
docker pull cartesi/rollups-node:X.Y.Z
Go to the Releases page and edit the current release by:
- unchecking the
Set as a pre-release
; - checking the
Set as the latest release
.
Remember to save the changes after that.
Once the release information is updated, announce it on the appropriate communication channels. The announcement should contain:
- the release number;
- a link to the tag/release;
- instructions on how to pull the corresponding docker image from Docker hub.
Either create a maintenance branch for any major or minor release and name it as release/X.Y.x
or update an existing maintenance branch if the release is a patch release.
Last but not least, prepare the CHANGELOG
for the next release by creating a new heading (## [Unreleased]
) in the beginning of the document.
Create a pull request based on the main
branch and merge it once it's approved.