# Release checklist # ## When the release managers for version `X.X` get nominated ## - [ ] Create a new issue to track the release process where you can copy-paste the present checklist from `dev/doc/release-process.md` (we recommend duplicating the "For each release" section for X.Y+rc1 and for X.Y.0, removing the useless entries in each copy). - [ ] Decide the release calendar with the team (date of branching, preview and final release). - [ ] Create a wiki page that you link to from https://github.com/rocq-prover/rocq/wiki/Release-Plan with this information and the link to the issue. ## About one month before the branching date ## - [ ] Create both the upcoming final release (`X.X.0`) and the following major release (`Y.Y+rc1`) milestones if they do not already exist. - [ ] Send an announcement of the upcoming branching date on the Rocq development category on Discourse (rocq+rocq-development@discoursemail.com) and ask people to remove from the `X.X+rc1` milestone any feature and clean up PRs that they already know won't be ready on time. - [ ] Prepare a PR on `master` (not yet to be merged) changing the version to the next minor version in [`tools/configure/configure.ml`](../../tools/configure/configure.ml). For example, for `9.3`, `minor` will be `3`. On master the `patch` value is always `Alpha`, so `rocq -version` will print `9.3+alpha` and the magic number will be `90299` (the release magic will be `90300` so we take the first number before that). This PR should be opened before the branching date to have time to deal with CI issues, but should not be merged until branching. ## On the branching date ## - [ ] Merge the above PR and create the `vX.X` branch from the last merge commit before this one (using this name will ensure that the branch will be automatically protected). - [ ] Set the next major version alpha tag using `git tag -s` (you can leave the tag message empty). The `VY.Y+alpha` tag marks the first commit to be in `master` and not in the `vX.X` release branch (be careful about sm…