New behavior in cargo.toml: adding minor versions

[yanns]

What would you like help with?

I think I found a bug

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

We are using cargo for rust projects.
For dependencies that we want to update once per week, we don't specify any minor version, like:

some_crate = "1.5"

The minor version is in the Cargo.lock file, for example 1.5.4.

We ask renovate to update the Cargo.lock file so that we can update all minor dependencies once a week in one PR.
That updates does not change Cargo.toml.

Recently, renovate opened lots of PR adding the minor version in Cargo.toml, like:

- some_crate = "1.5"
+ some_crate = "1.5.4"

This change does not have any impact on the application as the version 1.5.4 is already being used in Cargo.lock.

Those kind of changes creates lots of noise. And we would like to avoid them.

Either there are some recent changes that "broke" the previous behavior that was perfectly fine for us.
Or we might need to set a configuration flag to avoid those kind of PRs?

Any help appreciated.

Logs (if relevant)

No response

[viceice]

expected behavior:

• fix(versioning/cargo): bump simple versions to newVersion #28632
• feat(cargo): default to update-lockfile #28714

[yanns]

So once #28714 is merged, we should not see all those unnecessary PR updates anymore right?

[viceice]

yes

[yanns]

thanks a lot for the quick clarification! ❤️

[rarkins]

I've decided to backport this to v37: #28826

@nabeelsaabna can you deploy today?

[nabeelsaabna]

done
updated to latest 37.340.10

[yanns]

I'm still observing the same behavior with mend renovate:

The project does not specify any minor version in Cargo.toml:

[dependencies]
parking_lot = { version = "0.12", features = ["hardware-lock-elision"] }

[rarkins]

Also this does not sound like "same behavior" as you originally described, because you originally described behavior where the toml file was unnecessarily changed. Please clarify why you consider it "same" behavior if I've misunderstood something.

[yanns]

ah yes you're right. This is a new behavior, but different from the one I've originally described.
Before, those kind of updates were not opened as PR.
As we're using:

  "lockFileMaintenance": {
    "enabled": true
  }

the lock file was updated once per week, avoiding having lots of individual PRs.
doc

Should I open a new discussion for this?

[rarkins]

No, read the docs on rangeStrategy and then configure it to "replace"

[rarkins]

Lock file maintenance is an inferior solution to what you're getting now though, because you won't know what's updated in each PR. Better to group and schedule the current PRs.

[yanns]

Lock file maintenance is an inferior solution to what you're getting now though, because you won't know what's updated in each PR. Better to group and schedule the current PRs.

Yes it has its advantages. Thanks for the info.