r2r-ctd uses CalVer in the format YYYY.0M.X where X is the 0 based release number that month.
For example, the first release was 2025.08.0, had another release occurred that month, it would have been 2025.08.1.
When a commit is tagged, that exact state of the repository becomes the tagged version, so you want the state of the repository to be exactly what you want to be (no placeholder content, tests passing, etc..).
The correct tag for a release is the version string above prefixed with a v character.
For the above two examples, the git tags would be v2025.08.0 and v2025.08.1
This tag value is what gets used automatically by the build/publish system for a version number. Note that the python machinery will drop the leading zeros from the month.
- Do a "prepare" commit to the CHANGELOG.md file that sets the release version and date. Take this time to review the items in the changelog for anything that might need fixing or updating. Look at previous examples.
- Wait for or make sure all the CI tasks are completing: tests, docs building etc.. before continuing. Fix anything breaking.
- Start to draft a new release on the github releases interface. a. Click the "Draft new release" button in the upper right. b. Set the release tag to the correct value: type it in and pick the "Create new tag" option c. The release target should be the master branch d. Write a title, should include the version tag value and maybe something clever if you can think of it (have fun) e. Make the release notes, try using the "Generate release notes" button and see if that gets everything you need. Otherwise include at the minimum the contents of the changelog for this release. f. Have the "Set as the latest release" check box checked.
- Click the green "publish" button.
- This should trigger a publish GH action that builds and publishes the package to pypi. Check to make sure it actually worked.
- The release version will also be archived to zenodo as a new version.
- If needed, announce to folks in R2R who are using the software.