Christian Legnitto 28c116411d

Switch releasing commands from a blocklist to an allowlist (#956 )

* Switch releasing commands from a blocklist to an allowlist

This is much better as we can hardocde the crates to filter out in
one place, can selectively release certain crates easily,
and only have one command instead of the "-some" hack

* get rid of workaround no longer needed

* More makefiles

2021-07-07 23:47:16 -07:00

3 KiB

Raw Blame History

How to release new crate versions

Prerequisites

It is generally best to start with a clean respository dedicated to a release so that no git weirdness happens:

git clone git@github.com:graphql-rust/juniper.git juniper_release;
cd juniper_release;

We use the nightly toolchain when releasing. This is because some of our crates require nightly:

rustup default nightly

We use cargo-make and cargo-release to automate crate releases. You will need to install them locally:

cargo install -f cargo-make
cargo install -f cargo-release

Preparing for a release

There are two general classes of releases:

All public workspace crates should be released and all share the same release level ("patch", "minor", "major").
A subset of workspace crates need to be released, or not all crate releases share the same release level.

All release commands must be run from the root directory of the repository.

Determine new release level

For each crate, determine the desired release level (patch, minor, major). Set the RELEASE_LEVEL env variable to the desired release level.

Determine which crates to release

If a subset of workspace crates need to be released, or not all crate releases share the same release level, set the CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS env variable to choose specific workspace crates. The value is a list of semicolon-delineated crate names or a regular expressions.

Dry run

It is a good idea to do a dry run to sanity check what actions will be performed.

For case #1 above, run cargo make release-dry-run.
For case #2 above, run CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS="crate1;crate2" cargo make release-dry-run.

If the command finishes super quickly with no output you likely did not set RELEASE_LEVEL.

Local test

Not everything is captured in the dry run. It is a good idea to run a local test. In a local test, all the release actions are performed on your local checkout but nothing is pushed to Github or crates.io.

For case #1 above, run cargo make release-local-test.
For case #2 above, run CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS="crate1;crate2" cargo make release-local-test.

If the command finishes super quickly with no output you likely did not set RELEASE_LEVEL.

After, your local git repository should have the changes ready to push to Github. Use git rebase -i HEAD~10 and drop the new commits.

Release

After testing locally and via a dry run, it is time to release. A release consists of bumping versions, starting a new changelog section, pushing a tag to Github, and updating crates.io. This should all be handled by running the automated commands.

For case #1 above, run cargo make release.
For case #2 above, run CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS="crate1;crate2" cargo make release.

If the command finishes super quickly with no output you likely did not set RELEASE_LEVEL,

3 KiB Raw Blame History