Two-phase release

[sunng87]

Another scenario I have been thinking about is to support release proposal. I'm not sure if cargo-release really wants to cover the whole process. Typically it's like:

• going to propose a release
• prepare release notes
• cargo prepare-release:
  • create a release branch and bump version
  • create a github pull request titled like "Vote: Release 1.0.0"
• pull request approved and merged
• travis or other CIs received notification and run cargo perform-release to actually merge the release branch and publish to crates.io

This process could work for projects maintained by several devs or a committee. At the moment, cargo-release only works well for personal development.

[lucab]

You may be interested in how we (CoreOS/RedHat) perform team-reviewed releases using cargo-release:

• https://github.com/coreos/afterburn/blob/v4.4.0/.github/ISSUE_TEMPLATE/release-checklist.md
• https://github.com/coreos/afterburn/issues?q=label%3Akind%2Frelease+

[sunng87]

Thanks @lucab !

Your process is almost compatible with the one I described. I might not support github pull request/issue creation (possible to hook into prepare-release), but it's definitely possible to cover git branching in cargo-release. Thanks for letting me know your case.

[ryankurte]

it'd be super neat to have a way to run cargo release with protected main branches, which i think is basically the same scenario as this (though usually we'd manually review and merge via github / bors, so even just the first half that creates the branch and updates cargo.toml would be useful imo)

[passcod]

I've got this kind of workflow for my own (and, coincidentally, for Ryan's cargo-binstall) crates, and I've just made a github action that provides support for it: https://github.com/cargo-bins/release-pr

[epage]

With the upcoming 0.22 release, users will be able to create their own two-phase release

Workflow 1

Assuming the CHANGELOG is always valid

A contributor runs:

$ cargo release version patch -x
$ git commit -a -m "..."

and creates a PR. CI runs cargo release --unpublished. If it fails with code=2, then nothing needs to release. If it succeeds, there is something to release.

The PR gets merged.

Pushes to main trigger running cargo release --unpublished -x. This runs replacements, commits, publishes, tags, and pushes.

Workflow 2

A contributor runs:

$ cargo release patch -x
$ cargo release replace -x
$ git commit -a -m "..."

and creates a PR. CI runs cargo release publish --workspace && cargo release tag --workspace && cargo release push --workspace to show what will be published, tagged, and pushed. We'll automatically skip things that don't need to be published or tagged.

The PR gets merged.

Pushes to main trigger running cargo release publish --workspace && cargo release tag --workspace && cargo release push --workspace. That last push should only push tags, not branches.

Neither of these workflows work with dev-version-ext.

[epage]

v0.22 is now out.

The main question I've had for myself is if the individual subcommands are sufficient or if we should offer a cargo release prepare which is an alias for patch, replace, hook, and commit.

[DJDuque]

So, I found this issue after opening #809 and #810 (sorry).

The "two-phase" release I ended up with after reading this is:

• Step 1 (prepare the release):

  git switch -c $NEW_BRANCH
  cargo release --execute --no-publish --no-tag --allow-branch=$NEW_BRANCH $NEW_VERSION
  # Then make a PR
  

• Step 2 (actual release):

  # Merge the PR, and then from main:
  cargo release publish --execute
  cargo release tag --execute
  cargo release push --execute
  

Maybe fixing #810 could make things even better for step 2 e.g. cargo release --execute --no-replace