- Make a dedicated branch to prepare the release. All features, bugfixes, etc. intended for the release should already be in the
dev
branch. Some small fixes can be done in the release branch. As the branch should be named after the intended release version, check if a minor version bump is sufficient or a major version bump is required. Tools like cargo-semver-checks can be used for support.git checkout dev
cargo semver-checks check-release -p matlab-sys
git checkout -b release-_version_
- Make sure everything works and all tests pass!
cargo xtask test
- Give the documentation and the README a last look-over.
- Bump the version number in
./matlab-sys/Cargo.toml
to the previously decided upon version. - Commit the version bump and any other last minute changes
- Make a publishing dry-run
cargo package -p matlab-sys
cargo publish -p matlab-sys --dry-run
- Switch to the
master
branch for the release, merge therelease-_version_
branch and tag the commit onmaster
.git switch master
git merge --no-ff release-_version_
git tag -a _version_
- Push master.
git push origin master
git push --tags origin
- Publish the release to crates.io with the custom publish task.
cargo xtask publish
- Merge the changes made in the
release-_version
branch back into thedev
branch. git checkout dev
git merge --no-ff release-_version_
- Clean up the release branch, the next release will get a new branch.
git branch -d release-_version_
The workflow described above follows the advice on https://nvie.com/posts/a-successful-git-branching-model/