Releases management

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 will use the calendar versioning semantic that we have used for QeApp thus far. Specifically, we will release versions in April and October of each year, with the version numbers following the format [YEAR].04.xx and [YEAR].10.xx.

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. The principle behind this approach is that new features will only go into upcoming releases, while bug fixes will focus on the published release.

This approach offers several advantages. First, we can continue working on new features without breaking the in-use release. Second, 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). Third, 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.

We have the branch support-v23.04.x for commits that need to be cherry-picked to the stable version before the developing v23.10.0 is released.

To bump version need to run with --set-version explicitly.

bumpver update --set-version v23.04.2 --dry