docs/release-guide: add RELEASE_LEVEL variable for cargo release#56
docs/release-guide: add RELEASE_LEVEL variable for cargo release#56steveej wants to merge 1 commit intocamallo:masterfrom
Conversation
| * `cargo clean` | ||
| * `git clean -fd` | ||
| * `export RELEASE_VER=x.y.z` | ||
| * Depending on which version level this release increases, choose one of *major*, *minor*, or *patch* according to [semantic versioning][semver] |
There was a problem hiding this comment.
Except for this release where we messed up a bit before, I think we don't need this in general. We bump the relevant field when we introduce a breaking (or automatically right after the release commit), and then cargo release only takes care of stripping the suffix.
There was a problem hiding this comment.
So you bump the release manually in the Cargo.toml? Because I didn't and relied on cargo release to do that for me.
There was a problem hiding this comment.
If we need to bump major or minor, yes. That happens due to an API change/break anyway, so it can be done in the same PR. As I said, 0.2.1 flow was different because 0.2.0 never really happened.
There was a problem hiding this comment.
I don't think it was different. I introduced consistency by manually bumping the version in 621eac2, so that cargo release was able to make the changes on its own.
There was a problem hiding this comment.
Yes, but there was still a commit missing for the development bump (like d34e912).
There was a problem hiding this comment.
If I try to cargo release then it'll suggest a patch-level bump. In case I wanted to bump another level I'd have to specify that. What am I missing?
There was a problem hiding this comment.
See a real-world example at coreos/afterburn@01767df#diff-80398c5faae3c069e4e6aa2ed11b28c0. The corresponding cargo-release run then was https://github.com/coreos/coreos-metadata/pull/115/commits.
There was a problem hiding this comment.
I'll wait this one out until the next release ;-)
2 participants
No description provided.