Skip to content

Commit

Permalink
docs: describe release process
Browse files Browse the repository at this point in the history
  • Loading branch information
marcelstanley committed Apr 12, 2024
1 parent 746c45b commit 15fb330
Show file tree
Hide file tree
Showing 2 changed files with 96 additions and 0 deletions.
4 changes: 4 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,10 @@ Check the [development](docs/development.md) page for more information about dev
This document covered the features of the Node and its external APIs in a high-level manner.
Check the [architecture](docs/architecture.md) page for more details about the Node internal components.

## Releasing

Check the [release](docs/release.md) page for more information about the steps to release a version of the Rollups Node.

## Contributing

Thank you for your interest in Cartesi!
Expand Down
92 changes: 92 additions & 0 deletions docs/release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# Release process

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.

## Pre-release procedure

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](https://github.com/cartesi/rollups-node/blob/main/.github/ISSUE_TEMPLATE/update-dependencies.md).

## Pull latest changes

On your local machine, make sure to pull the latest changes made to the `main` branch.

## Perform tests

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`](../CHANGELOG.md)

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](https://github.com/cartesi/rollups-node/commit/16ba20137a1575b98d069500168261cccb2e0eb2) may be found in the repository.
## Create the release tag

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:

```shell
git tag -a vX.Y.Z
```

Make sure to add a message to the tag commit as follows:

```txt
Release X.Y.Z
```

Then, push the tag to th repository:

```sh
git push origin vX.Y.Z
```

## Check CI results

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:

```shell
docker pull cartesi/rollups-node:X.Y.Z
```

## Update release information

Go to the [Releases page](https://github.com/cartesi/rollups-node/releases) 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.

## Announce the release

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.

## Update/create a maintenance branch

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.

## Prepare for the next release

Last but not least, prepare the [`CHANGELOG`](../CHANGELOG.md) 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.

0 comments on commit 15fb330

Please sign in to comment.