Avoid unnecessarily tightening semver requirements
uint opened this issue · comments
Motivations
This concerns projects with multiple interdependent packages. When release-plz bumps package versions, it's also smart enough to bump the semver requirements wherever those packages appear in the dependencies section of other packages. That's kind of awesome.
What bugs me is that this happens even when there are no API breaking changes, a.k.a it's not needed, and usually not desirable.
See the example screenshots. cw-storey depends on storey @ >=0.1.0, <0.2.0. release-plz is trying to change the semver requirement to >=0.1.1, <0.2.0, which is not needed for cw-storey to accept storey 0.1.1. It does however block storey 0.1.0 from being selected in downstream projects, even though it would in all likelihood be fine.
- Would you like to implement this feature? [y/n]
I can help out with the boring stuff if there's a plan for how this would fit into the existing design. I know nothing about the internals of this project.
Solution
I imagine the new behavior could be to only bump semver requirements when the dependency's version bump makes it fall out of the range.
This could be an opt-in, configurable thing, but I'd argue for it becoming the default. Many Rust devs tasked with library maintenance believe semver requirements are version numbers that need to always be "bumped to the latest". When automated tools follow similar logic, they tend to perpetuate the misconceptions, especially since these tools may seem a bit of an authority.
Alternatives
As a workaround, I can try to set up separate CI workflows for each crate... maybe?
Additional context
this is related to #1181
If you change from
storey = { path = "crates/storey", version = "0.1.0" }
to
storey = { path = "crates/storey", version = "0.1" }
release-plz won't bump the dependency 👍
Does this work for you?
Ah, I didn't realize. I can work with that.
If I understand this well, it still means if someone puts down e.g. 0.1.1 in there for some legitimate reason ("0.1.0 doesn't have a __private API I'm relying on"), they'll end up with unnecessary bumps, but it sounds like a marginal issue.
I'm not sure I got your question 🤔
But if you specify
storey = { path = "crates/storey", version = "0.1.0" }
and you publish storey 0.1.1, then when people run cargo update they will download storey 0.1.1. The same is true for version = "0.1".
Now that I think about it, the requirement version = "0.1.0" should be identical to version = "0.1" from cargo's point of view
It works OK in my case: I can make cw-storey depend on storey @ 0.1 and not get the bumps, as you say. I'm happy if you want to close the ticket.
I was trying to say I can (maybe?) see a case where it doesn't work so well. If cw-storey 0.1.1 cannot use storey 0.1.0 for some legitimate reason, I'm forced to put down storey = "0.1.1" (or ^0.1.1, or >=0.1.1, <2) in the dependencies of cw-storey. I still probably don't want to get automated bumps of that semver requirement with every release of storey, but I will, without choice.
I see your point now. You are right, and I agree.
How would you like release-plz to behave?
Is your proposal that release-plz shouldn't update the version if the change is compatible? (E.g. 0.1.0 to 0.1.1)
How would you like release-plz to behave? Is your proposal that release-plz shouldn't update the version if the change is compatible? (E.g. 0.1.0 to 0.1.1)
That's what I was thinking.
I wrote this proposal here. We can discuss this in the other issue, thanks!