Dev Docs: Release

Most of the release process for csm is automated.

The steps are the following, both for pre-releases and normal releases:

In your local clone of the repo (replace x.y.z in all commands with the version number like 1.0.0 or 1.1.0-alpha7):

• If you have direct commit access, you can do this directly on main, otherwise create a branch and do the normal PR flow.
• Ensure a clean state (git status), stash changes if necessary.
• Bump version number in Cargo.toml
• Build with cargo build - this is mainly to bump the version in Cargo.lock
• git add Cargo.toml Cargo.lock && git commit with some message like "Release x.y.z"
• git tag x.y.z
• Here, if you have push access, you can push the version bump directly to main (git push origin main)
• Push the tag: git push origin x.y.z -- this is what triggers the actual release workflow

After that, on GitHub, go to the "Actions" tab and find the running release workflow. The release workflow will do the following:

• Run a preflight check to ensure version consistency (tag matches version in Cargo.toml)

• Run normal CI on the version about to be released

• Make release builds for each build target we support

• Publish those into a GitHub release for people to download

• Test a few of the targets as a sanity check to ensure the released artifacts actually run.

• If it all ends up being green, you're done!

• If something fails, you can typically just "Re-run failed jobs" from the GitHub page -- sometimes CI can flake since we depend on conda and micromamba downloads to work

• If everything goes wrong, you can just delete the release from the GitHub repo altogether.