I just released a workspace, and cargo release failed to verify a tarball. The tarball was valid though, it was just that one of its dependencies was uploaded to crates.io only seconds before, which was apparently not enough for crates.io to process the dependency. Running publish on the same crate again after a few more seconds worked totally fine.

The same effect occurred when doing a release completely manually without cargo release. Again, waiting a few seconds between releasing the two crates that depend on each other fixed the problem.

Therefore I propose to not abort if a tarball fails to verify, but instead to wait a few seconds and try again.

In workspace projects, it is often desired to create coordinated releases with all package versions bumped at the same time. This includes upgrading versions in dependent crates. It would be great to have some sort of workspace flag, that performs all upgrades in a single commit (and tag).

Maintainer Notes

Steps

• [x] Make core functionality independent of CWD
• [x] Properly update lock file in a workspace
• [x] #77 Verify / update corresponding version for path dependencies
• [ ] Create clap-cargo to at least contain workspace flags, making the processing of cargo-metadata reusable for other plugins
• [ ] #93 Figure out config semantics
• [ ] Support processing workspaces

Hey there,

I'm not sure whether this is strictly an issue, but it took me some time to work out and seems like a bit of a pain.

When cargo release X is run the version is bumped, the crate is published, then the version is again bumped to a development version. As cargo expects patch versions to match, this final bump means that you can no longer use [patch] overrides against the currently published library version for testing (without reverting the crate version in the patched crate's Cargo.toml).

This results in errors like:

warning: Patch `rr-mux v0.4.1-alpha.0 (/home/ryan/projects/rr-mux)` was not used in the crate graph.

Where the project cargo.toml contains:

[dependencies]
rr-mux = "0.4.0"
...

[patch.crates-io]
rr-mux = { path = "../rr-mux" }

One fix is to always run cargo release with --no-dev-version to avoid the problem.

My suggestion would be that that the second development version bump should be opt in, I didn't expect it to happen, but, either way there's now some documentation for anyone else who has the same problem.

Hi there!

I'm trying to adapt cargo-release to work for nextest. The nextest workspace consists of several crates, each with their own independent versioning.

If I'd like to update one of nextest's crates, I'd like to be able to do:

cargo release -p nextest-filtering 0.2.2 --execute

and have a commit be created with the requisite version bumps and the message:

[nextest-filtering] version 0.2.2

and a signed tag created on this commit called nextest-filtering-0.2.2 with message:

nextest-filtering version 0.2.2

Here's my first attempt at configuring that, based on the reference:

https://github.com/nextest-rs/nextest/blob/main/release.toml

However, when I run:

cargo release -p nextest-filtering 0.2.2 --execute

the commit that gets created is:

commit 49aaac68f9fae149b957ed79508e3551cd20d816 (HEAD -> main)
Author: Rain <[email protected]>
Date:   Fri Oct 14 12:23:50 2022 -0700

    [{{crate_name}} version {{version}}

which indicates that template replacements aren't working.

Any idea how to make them work?

% cargo release --version
cargo-release 0.21.4

Cargo supports having metadata in it's version numbers: https://doc.rust-lang.org/cargo/reference/resolver.html#version-metadata

In the https://github.com/gfx-rs/rspirv/ crate we're using this to specify which upstream SPIR-V headers we're compiling against while keeping our own releases compatible with SemVer. However, cargo dependencies can't contain metadata information.

So for example; a package has version of 0.1.0+1.54 for example, in it's Cargo.toml file, the version should still be listed as 0.1.0.

Right now when we're using cargo release we specify the version number like so cargo release -- 0.1.0+1.54, however this populates the {{version}} regex replacement attribute with 0.1.0+1.54 which isn't valid in a lot of cases. Ideally it should strip everything after the + sign and emit that (or alternatively there ought to be a {{version_no_metadata}}.

With your help in the previous issue, I could cut a 0.5.0 release of chars, thanks for that! Unfortunately, the process failed when it was bumping the dev versions for the two crates:

:;    cargo release minor --verbose
[2020-03-20T13:38:50Z DEBUG] Files changed in chars_data since chars_data-v0.4.1: [
        "/Users/asf/Hacks/chars/chars_data/chars_data/Cargo.toml",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/entities/LICENSE",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/entities/README.md",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/entities/entities.json",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/entities/retrieve.sh",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/unicode/NameAliases.txt",
        "/Users/asf/Hacks/chars/chars_data/chars_data/data/unicode/UnicodeData.txt",
        "/Users/asf/Hacks/chars/chars_data/chars_data/src/ascii.rs",
        "/Users/asf/Hacks/chars/chars_data/chars_data/src/fst_generator.rs",
        "/Users/asf/Hacks/chars/chars_data/chars_data/src/unicode.rs",
    ]
[2020-03-20T13:38:50Z DEBUG] Files changed in chars since v0.4.1: [
        "/Users/asf/Hacks/chars/chars/chars/Cargo.toml",
        "/Users/asf/Hacks/chars/chars/chars/release.toml",
        "/Users/asf/Hacks/chars/chars/chars/src/display.rs",
        "/Users/asf/Hacks/chars/chars/chars/src/unicode/mod.rs",
        "/Users/asf/Hacks/chars/chars/chars/tests/human_names.rs",
    ]
    ]
Release
Release
  chars_data 0.5.0
  chars 0.5.0
? [y/N]
y
[2020-03-20T13:38:53Z INFO ] Update chars_data to version 0.5.0
[2020-03-20T13:38:53Z INFO ] Fixing chars's dependency on chars_data to `^0.5.0` (from `^0.4.1-dev`)
[2020-03-20T13:38:53Z INFO ] Update chars to version 0.5.0
[2020-03-20T13:38:54Z DEBUG] Substituting values for /Users/asf/Hacks/chars/chars/../CHANGELOG.md
[2020-03-20T13:38:54Z DEBUG] Substituting values for /Users/asf/Hacks/chars/chars/../CHANGELOG.md
[2020-03-20T13:38:54Z DEBUG] Substituting values for /Users/asf/Hacks/chars/chars/../CHANGELOG.md
[master 08543b9] Release {{version}} 🎉🎉
 4 files changed, 8 insertions(+), 6 deletions(-)
[2020-03-20T13:38:54Z INFO ] Running cargo publish on chars_data
    Updating crates.io index
   Packaging chars_data v0.5.0 (/Users/asf/Hacks/chars/chars_data)
   Verifying chars_data v0.5.0 (/Users/asf/Hacks/chars/chars_data)
   Compiling memchr v2.3.3
   Compiling fst v0.4.0
   Compiling lazy_static v1.4.0
   Compiling regex-syntax v0.6.17
   Compiling unicode-width v0.1.7
   Compiling quick-error v1.2.3
   Compiling unicode_names2 v0.4.0
   Compiling thread_local v1.0.1
   Compiling getopts v0.2.21
   Compiling aho-corasick v0.7.10
   Compiling regex v1.3.5
   Compiling regex v1.3.5
   Compiling chars_data v0.5.0 (/Users/asf/Hacks/chars/target/package/chars_data-0.5.0)
    Finished dev [unoptimized + debuginfo] target(s) in 24.07s
   Uploading chars_data v0.5.0 (/Users/asf/Hacks/chars/chars_data)
[2020-03-20T13:39:47Z INFO ] Waiting for publish to complete...
[2020-03-20T13:39:50Z INFO ] Running cargo publish on chars
    Updating crates.io index
   Packaging chars v0.5.0 (/Users/asf/Hacks/chars/chars)
   Verifying chars v0.5.0 (/Users/asf/Hacks/chars/chars)
  Downloaded chars_data v0.5.0
   Compiling memchr v2.3.3
   Compiling fst v0.4.0
   Compiling lazy_static v1.4.0
   Compiling unicode-width v0.1.7
   Compiling regex-syntax v0.6.17
   Compiling unicode_names2 v0.4.0
   Compiling quick-error v1.2.3
   Compiling byteorder v1.3.4
   Compiling thread_local v1.0.1
   Compiling getopts v0.2.21
   Compiling aho-corasick v0.7.10
   Compiling regex v1.3.5
   Compiling chars_data v0.5.0
   Compiling chars v0.5.0 (/Users/asf/Hacks/chars/target/package/chars-0.5.0)
    Finished dev [unoptimized + debuginfo] target(s) in 45.72s
   Uploading chars v0.5.0 (/Users/asf/Hacks/chars/chars)
[2020-03-20T13:40:38Z INFO ] Waiting for publish to complete...
[2020-03-20T13:40:44Z DEBUG] Creating git tag chars_data-v0.5.0
[2020-03-20T13:40:44Z DEBUG] Creating git tag v0.5.0
[2020-03-20T13:40:44Z INFO ] Starting chars_data's next development iteration 0.5.1-dev
[2020-03-20T13:40:44Z WARN ] Fatal: Invalid TOML file format: Error during execution of `cargo metadata`: error: no matching package named `chars_data` found
    location searched: /Users/asf/Hacks/chars/chars_data
    prerelease package needs to be specified explicitly
    chars_data = { version = "0.5.1-dev" }
    required by package `chars v0.5.0 (/Users/asf/Hacks/chars/chars)

So, looks like what's happening in that stage is:

1. It bumps the version of chars_data to 0.5.1-dev
2. It tries to bump the dependency in chars on chars_data to 0.5.1-dev
3. at that point, cargo refuses to find dev release version dependencies with no exact match -> error

I think I saw a cargo bug to that effect before, but I can't find it at the moment. I wonder if you can even do that bump with any in-flight versions of files. I imagine that the process might have to be:

1. Bump the version of chars_data to 0.5.1-dev but keep the previous Cargo.toml in place (save the update to a temp file, probably?)
2. Bump the dependency version in all dependent crates while cargo metadata still agrees, but also keep those old Cargo.toml files in place
3. Move all the temp files into place

This adds a command line parameter --publish-grace-sleep that defines how long we wait between two invocations of cargo publish. The default value is 5.

In a workspace, I need to define my dependencies as dep = { path = "../dep", version = "0.1.0" } but I forget (until cargo publish) to update the versions for my path dependencies (and it is really annoying).

I think building this into cargo-release would be a big help.

I view this as a subset of the work for #66. While that is for releasing an entire workspace, this will help with releasing parts of a workspace (and is needed for the entire workspace).

Configuration

• What to do on path dependency
  • verify
  • bump to latest (has to check crates.io because local path dependency has probably been bumped post-publish)
  • bump to semver compatible version

I have a workspace with multiple crates that depend on each other, with the dependency specified via a path. Before release, I had the following dependencies of the genome-graph crate:

[dependencies]
bigraph = {path = "../bigraph", version = "0.1.0-alpha.4"}
compact-genome = {path = "../compact-genome", version = "0.1.0-alpha.4"}
num-traits = "0.2"
bio = "0.31"
error-chain = "0.12"

The version of bigraph in the workspace was 0.1.0-alpha.4. I then executed cargo release alpha on the workspace root, which bumped the versions of all crates and released them as expected. But it did NOT bump the versions in the [dependencies] sections. As a result, the released genome-graph crate has version 0.1.0-alpha.5, but still points to bigraph version 0.1.0-alpha.4, which is wrong.

How do I get cargo-release to bump also the versions in the declaractions of [dependencies]?

error: failed to publish to registry at https://crates.io

Caused by:
  the remote server responded with an error (status 429 Too Many Requests): You have published too many crates in a short period of time. Please try again after Thu, 30 Jun 2022 15:07:44 GMT or email [email protected] to have your limit increased.

$ HEAD_OUTPUT=$(git diff HEAD --exit-code --name-only)
$ echo Head Output=$HEAD_OUTPUT
Head Output=
$ LS_OUTPUT=$(git ls-files --exclude-standard --others)
$ echo LS Output=$LS_OUTPUT
LS Output=
$ RUST_LOG=trace cargo release --no-confirm --no-dev-version --tag-name "{{crate_name}}-{{prev_version}}" -vv patch
[2019-12-18T18:51:27Z WARN ] Uncommitted changes detected, please commit before release.

Git status also indicates a clean working directory. Not sure what it is error'ing on.

If I run cargo release in the root of: https://github.com/kornelski/cavif-rs commit b2f707ce08bf758048cb967998df92d8dd3d2c7c

https://github.com/kornelski/cavif-rs/tree/b2f707ce08bf758048cb967998df92d8dd3d2c7c/

it chooses not to publish workspace's leaf dependency first (ravif), and then the root crate fails validation (cavif), because its dependency isn't published yet.

$ cargo release
warning: disabled by user, skipping ravif which has files changed since v1.4.0: [
    "./cavif/ravif/Cargo.toml",
    "./cavif/ravif/src/av1encoder.rs",
    "./cavif/ravif/src/dirtyalpha.rs",
    "./cavif/ravif/src/error.rs",
    "./cavif/ravif/src/lib.rs",
]
warning: disabled by user, skipping ravif v0.9.3 despite being unpublished
  Publishing cavif
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   ./cavif/ravif/Cargo.toml
workspace: ./cavif/Cargo.toml
    Updating crates.io index
   Packaging cavif v1.4.1 (./cavif)
error: failed to prepare local package for uploading

Caused by:
  failed to select a version for the requirement `ravif = "^0.9.2"`
  candidate versions found which didn't match: 0.9.1, 0.9.0, 0.8.9, ...
  location searched: crates.io index
  required by package `cavif v1.4.1 (./cavif)`

I don't see why cargo-release thinks the dependency is "disabled by user".

Using cargo-release 0.24.0 and rustc 1.65

I am publishing https://github.com/n0-computer/iroh using [email protected] but unfortunately it determines an incorrect order and aborts half way through: iroh-resolver is attempted to be published before iroh-store, which fails due to their dependency.

Hey there!

Earlier this week I was trying to release a series of crates from the ink! repository. I was able to successfully perform a dry run, but when I went to actually publish the release I ran into a permissions issue.

Turns out I wasn't an owner of one of the crates and so I wasn't allowed to publish it.

It would be great to have cargo-release print out a warning as part of the dry-run if you don't have sufficient permissions to publish a crate.

Tested with [email protected].

Hi there --

I noticed that cargo-release 0.22 changed things so that it's now an error if there's nothing to publish: https://github.com/crate-ci/cargo-release/commit/4783fda710e3f4543472c5aabb38cdfbc920930e

I'm wondering if it would be possible to have a flag which makes it so that it no longer errors if there's nothing to publish. My use case is that I'm releasing a bunch of independently versioned crates and I'd like to move towards using cargo-release in CI to do the publishing. To avoid race conditions, I'd like the publish step of each crate to publish everything that can be published, to avoid race conditions between different release jobs. This is effectively an idempotent operation, which shouldn't fail if there's nothing to publish.

Alternatively, I could potentially say that if the exit code is 2, treat it as success. Does the exit code 2 always mean "nothing to publish" as part of the documented command-line interface?

Thanks!

For larger workspaces, this should offer some good savings, especially to overcome slow downs from waiting for crates to be published when nothing wait on them.

We should look into using jobserver support in cargo to limit the parallel builds.