Breaking change in minor version

[djmitche]

I see the

⚠️ Potential Breakage ⚠️

in the release notes for 1.8.0, and indeed this did break at least one of my projects. The fix isn't too hard, of course.

However, a lot of the logic around dependency handling takes the major / minor semver distinction seriously. For example, AIUI uuid-2.x and uuid-1.x could coexist in a single build, but uuid-1.7.0 and uuid-1.8.0 cannot. Similarly, dependabot can be configured to handle minor and major version bumps differently.

It would have been great for this breaking change to have been flagged as such to bots and humans alike, by calling it 2.0.

No immediate action is requested here, but if another breaking change comes along in a month or two, please consider releasing it as 2.0 and not 1.9.0. As a downstream consumer, I'd be much happier using uuid-14.0.0 in a few years, with the 12 major changes handled cleanly, than using uuid-1.20.0 and having had my build broken unexpectedly 12 times.

Thanks!

[KodrAus]

@djmitche Are you affected by this breakage? Rust's inference is prone to breakage through non-breaking API changes and is typically accepted in the standard library.

EDIT: Ah I missed the first part of your comment that it did affect one of your projects. The point still stands that inference breakage, while undesirable, is something that can happen in Rust.

[djmitche]

I agree that determining whether a change is breaking is challenging, although tools lke cargo-semver-checks or cargo-public-api help. This sort of breakage is particularly hard to spot, though!

In this case, it seems the breakage was known, as it is mentioned in #743 and in the release notes. I opened this discussion just to add a bias in favor of a major version bump in future such cases, to be measured against the cost of a major version bump.

Thanks for the crate!