Version bump loop in workspace

[Jacob Rothstein]

Bug description

I'm trying to use release-plz in a fairly large workspace and have discovered that every release updates workspace-local dependencies, which in turn makes release-plz think that a patch release is pending. Here's an example PR that was opened immediately after merging a release-plz chore: release PR. The primary concern here is that I'd like to avoid issuing patch releases that have zero meaningful changes, especially since there's no way to only release one crate at a time.

• Would you like to work on a fix? Sure! But I have no idea what the intended behavior is here, or if I'm using release-plz wrong, or if it's an inappropriate tool for my needs

[Marco Ieni]

every release updates workspace-local dependencies, which in turn makes release-plz think that a patch release is pending.

Yes, you are right. For example, in the PR you linked, trillium-api is updated because trillium went from 0.2.12 to 0.2.13.

I'd like to avoid issuing patch releases that have zero meaningful changes

If you don't want release-plz to bump that number, you can edit "0.2.12" to "0.2" here. Release-plz will only bump when "0.3.0" is released. Would this solve your issue? If not, do you want a config flag to disable workspace local dependencies update completely?

I'm using release-plz wrong, or if it's an inappropriate tool for my needs

I want release-plz to support complex workspaces like trillium, so if something is missing, let's work together to implement it!

[Jacob Rothstein]

My concern with using 0.2 instead of 0.2.12 is as follows, and please correct me if my understanding here is wrong: If the most recent version of some crate (eg trillium-api) depends on a feature that was introduced in trillium@0.2.10, it's not necessarily the case that 0.2.* would compile. In that case, it seems more correct to depend on trillium@0.2.13 explicitly than to use 0.2.*. Ideally probably I'd manually specify trillium = "^0.2.10" and only update it when necessary, but I don't at all mind that updating if updating one trillium-* crate makes cargo update other trillium-* crates to the latest patch versions without requiring cargo update.

I don't mind the version bumps to latest patch versions, but without having looked into release-plz's internals at all, I'd ideally want a way of excluding some commits from marking a workspace crate as in need of release or of easily excluding some crates from a release.

Some possible solutions that wouldn't require changing the version-bump logic:

If there were a release-required regex, the release-plz-created release commit would be included in the default exclusion list, to avoid cycles. This would also address the concern that bumping a dev-dependency or editing an example is not release-worthy, and neither are certain types of chore commits. Maybe git-cliff already supports this sort of exclusion?

Another way of addressing this would be to open one PR per workspace crate, allowing authors to manually ignore crates (close release PRs) that have insufficient changes to merit release.

Yet another way would be to allow @release-plz GitHub comments on release-plz PRs along the lines of "@release-plz ignore trillium-api" which would drop it from the current release PR or "@release-plz only trillium-client", which would drop everything other than trillium-client

[Marco Ieni]

If the most recent version of some crate (eg trillium-api) depends on a feature that was introduced in trillium@0.2.10, it's not necessarily the case that 0.2.* would compile.

You are right 👍

I don't at all mind that updating if updating one trillium-* crate makes cargo update other trillium-* crates to the latest patch versions without requiring cargo update.

I didn't get this. Can you explain it again if you think it's important?

I'd ideally want a way of excluding some commits from marking a workspace crate as in need of release or of easily excluding some crates from a release.

The code that determines if an update is needed is here. It's one of the most convoluted parts of the codebase, sorry in advance 😅

Here we can customize this algorithm as we wish. For example, the trillium-api is updated because release-plz compares the Cargo.toml file here.

You are saying we should add a configuration value to ignore local packages update in this diff (right now is a simple file comparison, but we could parse the Cargo.toml and check for diffs there).

If there were a release-required regex ..

So you are proposing to ignore commits that don't respect a certain regex. That's a great feature request, do you mind creating an issue?

Maybe git-cliff already supports this sort of exclusion?

Git cliff supports it, but we probably need to re-implement it in release-plz, because git-cliff is invoked later.

Another way of addressing this would be to open one PR per workspace crate, allowing authors to manually ignore crates (close release PRs) that have insufficient changes to merit release.

This is somehow tracked by #1029

Yet another way would be to allow @release-plz GitHub comments

Yes, we have something similar in mind for #704

[Bas Zalmstra]

I think I'm also running into this issue. This PR is created which bumps all crates even though only a single crate was updated (rattler_lock):

conda-incubator/rattler#542

Is there an existing workaround that I could use?

[Marco Ieni]

Is there an existing workaround that I could use?

What's your desired behavior?

Let's say you have two crates: aaa and bbb. aaa depends on bbb.

If bbb is at version 1.2.3, the Cargo.toml of aaa can look like this:

1. [dependencies]
   bbb = { path = "./b", version = "1.2.3" }

2. [dependencies]
   bbb = { path = "./b", version = "1.2" }

3. [dependencies]
   bbb = { path = "./b", version = "1" }

In which cases do you want to update the Cargo.toml of aaa if release-plz updates bbb version in the following ways?

a. 1.2.3 -> 1.2.4
b. 1.2.3 -> 1.3.0
c. 1.2.3 -> 2.0.0

At the moment, release-plz updates the Cargo.toml of aaa only if the bump is visible in the Cargo.toml.
For example:

• in case 1-a the Cargo.toml of aaa is updated, turning version = 1.2.3 into version = 1.2.4
• in case 1-b the Cargo.toml of aaa isn't updated because version = 1.2 is still valid (1.2.4 satisfies 1.2).

I hope this makes sense.
I couldn't look at your example you linked, because the release PR was already modified. Maybe you can provide screenshots or copy paste parts of the PR next time you want to provide an example. 👍

[Marco Ieni]

uint proposed here that release-plz shouldn't update the version if the change is compatible. (E.g. 0.1.0 to 0.1.1).
What do you all think? 🤔
I'm not too sure about this because if 0.1.1 contains a fix, then people should update the version manually which is boring, and people might forget to do it :/