Release Process

This is a reference document for project maintainers.

What is a release?

A release is defined as any code change to the main branch. In almost all cases this will be a pull request from development to main.

Release schedule

Generally, aim at updating main with development once a week. These will be considered regular maintenance releases and can include various smaller tasks or bug fixes. Larger releases centered around milestones can go out whenever the milestone is completed, with or without additional maintenance changes.

Before you create a release PR

1. Ensure that you have identified the next version number and updated the package.json version accordingly.
2. Make sure that the unit tests are all passing and that the build is in working order.
3. Check that relevant issues and their statuses are up to date. All issues in the release should be in "Done".

Get approval from another project maintainer

Before merging into main make sure your PR has a review from another code maintainer.

Create a new release after merging

Once the PR from development to main is merged, create a new release and associated tag (matching the package.json version). If it makes sense, use the "generate changelog" feature to quickly outline the changes in the release notes.

Update the Changelog wiki page

Add the new release version to the changelog wiki page and highlight the major changes underneath. Link to the release notes for detailed documentation on the changes.

Archive "Done" issues

Now that the release is complete, archive the "done" issues so that our project board doesn't become littered with old information.

Update relevant wiki documentation

Add or modify relevant wiki documentation pages.