cargo-release

My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks. I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including - You can't as easily introspect the process - You can't as easily recover from failure - Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult - When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version I have been considering making

You should combine step 1 and 2 in CI. Just tag a version in your git, push to remote and have CI auto build a release for you. Use github actions or other setup for other backends. (this is language agnostic and a reasonable thing to learn as a dev). Or if you must live in the cargo command, go nuts with cargo-release. https://github.com/crate-ci/cargo-release https://github.com/cargo-bins/release-pr

This is what I was used to at a prior day job (another one just didn't keep a version in source). When I took over cargo-release [0], this was also the default though not anymore. Benefits of keeping the last version - Easier to detect when a change occurred since the last release - (Rust specific) It makes it harder to patch a registry dependency with a git dependency because the versions will never align [1]. This is why the default changed in cargo-release. - The "next version" is just speculation. Will the next release bump the pre-release version, patch, minor, or major? A downside to keeping either last version or next version is if someone builds from master, the bug report could be confusing unless you include the git hash (and whether the repo was dirty). I've seen some advocate for not keeping a version in source at all [2].