-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version bump loop in workspace #1181
Comments
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.
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 want release-plz to support complex workspaces like trillium, so if something is missing, let's work together to implement it! |
My concern with using 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 |
You are right 👍
I didn't get this. Can you explain it again if you think it's important?
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).
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?
Git cliff supports it, but we probably need to re-implement it in release-plz, because git-cliff is invoked later.
This is somehow tracked by #1029
Yes, we have something similar in mind for #704 |
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): Is there an existing workaround that I could use? |
What's your desired behavior? Let's say you have two crates: If
In which cases do you want to update the Cargo.toml of a. 1.2.3 -> 1.2.4 At the moment, release-plz updates the Cargo.toml of
I hope this makes sense. |
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). |
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.The text was updated successfully, but these errors were encountered: