Publish after all local/remote source changes

[ryankurte]

hi hi,

thanks for making such a useful crate!

i think the order in which things are published is incorrect, leading to less than ideal package states on failure (as i discovered here.

for example, running cargo release with a protected master branch results in:

• the cargo.toml version being bumped (success)
• the changes being committed locally (success)
• the cargo package being pushed to crates.io (success)
• the repository being pushed to master (failure)

leaving the project with a published version on crates.io, without the matching source code.

i propose that the ordering be changed to:

• bump cargo.toml version
• commit local changes
• tag local changes
• push changes to remote
• push tag to remote
• publish to crates.io

so that if any of the source-related stages fail, the crate will not be published to crates.io.

[epage]

I've actually had the opposite experience with my manual releases and I've been looking forward to cargo-release's order (haven't switched yet; working on the features I need).

My problem is there have been times where my cargo publish has failed (particularly when first creating a crate) but I've already pushed my commits/tags so I update the version number again with my changes and try again.

So ideally we find a way to satisfy both use cases.

[epage]

for example, running cargo release with a protected master branch results in:

How protective is your master? The most basic is no force-push but I'm assuming there is more here, like no pushing at all.

Are you manually pushing to a branch to then create a PR? How do you propagate tags?

I'm wondering

• if other features might be needed for this case. For example, we support customizing the remote but not the branch.
• If there are ways to improve my workflow because I currently push directly to upstream/master because that is the only way I know of to get tags handled.

[ryankurte]

ooh, interesting~!

our usual release process uses bors, so you create a release branch with the cargo version update, merge that, then publish from master (and tag anywhere along the way).

which, thinking about more, it, may be too specific of a use case for this to work perfectly / maybe is better managed manually...

[epage]

cargo-release can still help in automating your process. You can disable publish and still rely on cargo-release to bump the version, run regexes, create the commit, etc.

And like I said, it might be reasonable to support changing what branch we push to, making it so you don't need to disable the push feature of cargo-release.

[epage]

@sunng87 from #101

The default behaviour is for the case that when release failed, for example, an error on cargo publish, the version is already bumped and we have a way to rerun cargo-release. Otherwise, it makes more sense to use patch by default.

To fix the rerun issue, also mentioned in #103 , I am going to add a transaction log file like maven release, so we can always rerun the failed process.

I find it odd that the default behavior is for resuming. In my mind, that should be explicit, with maybe calling the option resume with patch being the default.

EDIT: A transaction log seems like it could also be brittle (had problems in other tools with similar files). If maven makes it work, then maybe I'm overly concerned.

[epage]

For this request for its own sake, I'm going to reject this.

For bors workflows, I'm closing in favor of issues like #119 and #528 to further discuss it