Release Process

From https://github.com/Boavizta/cloud-scanner/issues/624#issuecomment-2526469649

The current semi manual release process involves:

• (optional) updating the dependencies to the latest version and check that test pass (cargo update cargo run test)
• updating cloud scanner version in the cloud-scanner-cli cargo.toml https://github.com/Boavizta/cloud-scanner/blob/main/cloud-scanner-cli/Cargo.toml
• updating the version in cloud-scanner-lambda cargo.toml: https://github.com/Boavizta/cloud-scanner/blob/main/cloud-scanner-lambda/Cargo.toml
• updating the tag of the image in docker-compose (using the not-yet-published version that we declared just above)
• updating the changelog.md (mention this new version, move unreleased entries under this new version)
• merge this changes to main
• create a github relase vX.Y.Z (i.e. in practice, this will tag the main branch with the tag 'vX.Y.Z` when the release is published), I generally tick the option to create a related discution in github https://github.com/Boavizta/cloud-scanner/discussions publish the release (which triggers the tagging, and consequently the build / publish of docker image in CI). Sometimes, if I fear a breaking change, I publish an -alpha or -beta release (like https://github.com/Boavizta/cloud-scanner/releases/tag/v2.0.0-alpha) and mark it as a pre-release in github, but generally not.
• Publish crate for CLI on crates.io (https://doc.rust-lang.org/cargo/reference/publishing.html)
• Update the version in the Cargo.toml files with -SNAPSHOT suffix
• Add the following to CHANGES ## Unreleased _This paragraph may describe WIP/unreleased features. They are merged to main branch but not tagged._ and push to main
• Edit the milestones: close the one for the version just released then create one for the new version