Skip to content

Releases management

Jump to bottom
Jusong Yu edited this page Jan 30, 2024 · 3 revisions

Releases management

  • All new features go to the next release
  • All crucial bug fixes go to the support release
  • If not sure, the implementation goes to the next release

The plan was made that rather than releasing QeApp on a monthly basis, we should aim to release two promising versions every year.

To implement this plan, we use the calendar versioning semantic, namely in the format vYY.MM.NUM Specifically, we will release versions in April (vYY.04.NN) and October (vYY.10.NN) each year.

To ensure that the upcoming releases are well-planned, we will document new big features on a wiki page, and all bug fixes will go to the patched version of the latest published release by using support/vYY.MM.NN branch. The principle behind this approach is that new features will only go into upcoming releases, while bug fixes will focus on the tested published release.

This approach offers several advantages:

  • we can continue working on new features without breaking the in-use release.
  • it will help trim down the list shown in the app manager so that users can easily see what they have installed (though this will require additional work on the app register filter to allow for the display of the latest patch of releases).
  • the new features will be foreseeable and tracked. Finally, the current release will become more robust and will not break any workflows, allowing reviewers (from MARVEL or Nicola M.) to use it at any time without issue.

The typical example is applied from the v23.10.0, which is the first self-trust release of the app.

Make the alpha release for next version ASAP

The alpha release v24.04.0a0 is create from main right after the v23.10.0 is officially released. The following up v24.04.0-xx pre-releases are from main branch and can be released by simply running (take v24.04.0a1 as example):

bumpver update --set-version v24.04.0a1 --ignore-vcs-tag

Note! please always use --dry before making release, the command will create tag and push the tag to the remote repo which trigger the release CI workflow.

Make the support release

Once the official release is created (take v23.10.0 as example), create a support branch from it, namely support/23.10.x and cherry pick commits to the branch and make patch releases by (take v24.04.2 as example suppose the v24.04.1 is the previous patch release.):

bumpver update --set-version v23.04.2
Clone this wiki locally