### When the previous release branch is created: - [x] Raise the library version (`MAJOR_VERSION`/`MINOR_VERSION`/`PATCH_VERSION` in CMakeLists.txt) on `main` - [x] Tag the commit where the library version is raised as `$major.$minor.$patch-dev` ### At the beginning of the 6 month release cycle: - [x] Appoint a release manager who is responsible for the release process and create the release issue with the contents of this document between the `start of issue`/`end of issue` comments - [x] Create a milestone with due date - [x] Fill the milestone with issues ### 6 weeks before the release date: - [x] Create an issue to update RELEASE_NOTES.md and assign it to someone else - [ ] Announce (slack: `kernel`) that there are two weeks left before the first release candidate - [ ] \(TSD maintainer\) Update TSD/distribution.properties to see if it works with cppTango - [x] \(TSD maintainer\) Create issues for all dependent subprojects and ask for an update ### 4 weeks before the release date: - [x] Determine if we have broken API/ABI compatibility for this release and make sure that the SO_VERSION is correct in the base CMakeLists.txt. - [x] Create a release branch named `release/$major.$minor.$patch` off `main`. From now on all merge requests for this release have to be done against this branch. - [x] Change the target branch of all MRs which should be part of this release to the new release branch - [x] Disable the `pages` job on the `main` branch #### RC phase: - [x] Tag the repo (`$major.$minor.$patch-rc$X`), this automatically creates a release and uploads the windows packages - [ ] \(TSD maintainer\) Update TSD to use the new tag, merge it and tag as well - [x] Advertise the new release candidate on the `tango-info` mailing list and mattermost (channel: `general`) During the RC phase it is advisable to only merge non-intrusive MRs to avoid the possibility of last-minute regressions. Creating a new release candidate should be redone every week when more MRs have been merged. ### At the release date: All steps from the release candidate phase above: - [x] Tag the release (`$major.$minor.$patch`) - [x] Update for TSD - [x] Advertise new release and finally - [x] ~~Delete release branch~~ No longer doing that, RELEASING.md will be changed - [x] Allow the `pages` job to run on `main` again