Breaking change released as 2.3.0, which causes build failures on upgrade about bitflags HOT 6 CLOSED

Thanks for the report @teor2345! This should be fixed if you run cargo update. That Bits associated type moved into a supertrait, so if you wrote:

T::Bits

it would continue to compile, but if you wrote:

<T as BitFlags>::Bits

then it wouldn't.

from bitflags.

We've had a few growing pains in bitflags 2.x, but this should be the last of them now. Thanks for sticking through everything 🙏

from bitflags.

Thanks for the report @teor2345! This should be fixed if you run cargo update.

Unfortunately, we can't run cargo update on our previous release tags, which have this build issue when they are built without --locked.

Rust's semantic versioning guidelines say that all minor version updates of a single crate should be compatible:
https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility

So for example, we should be able to build any version of bitflags 2.* with bitflags-serde-legacy 0.1.0. But building bitflags 2.3.0 or 2.3.1 with bitflags-serde-legacy 0.1.0 currently fails. This means that the incompatible crates should be yanked.

It might seem like upgrading to bitflags-serde-legacy 0.1.1 solves this issue, but that only works if every dependency in our dependency tree allows that upgrade. (This might seem like a trivial complaint, but it's actually happened to us before with other dependencies.)

Instead, if you make these kinds of changes in a major version, then Rust will compile two separate versions of your crate into the binary. So old code will remain compatible, and new code can continue to upgrade.

If you don't want to follow the guidelines, that's ok! But please put that in your README, so other projects can decide if they want to take that risk. We might decide that we don't want to take that risk, because we don't want this kind of breakage to happen in our production releases.

from bitflags.

That Bits associated type moved into a supertrait, so if you wrote:

T::Bits

it would continue to compile, but if you wrote:

<T as BitFlags>::Bits

then it wouldn't.

Unfortunately, these are public items, so the semantic versioning guidelines still technically apply.

from bitflags.

Thanks @teor2345, I do understand the rules of semver and how API evolution in Rust works. The case of having two versions of that trait was exactly what I needed to avoid here because that would have required you to then issue a major breaking version of your own code. So on balance, I took a route that allowed us to evolve that trait without triggering widespread incompatibility.

I also appreciate the frustration of random build breakages in your production code. The fact that the Rust community has a culture of rigor around safety and compatibility is absolutely a good thing, but all external code comes with some level of risk and this is trivially fixed without you needing to make any changes yourself. I try to support you as a user as much as any other and take semver compatibility seriously, but can't always please everybody. I don't plan on yanking this release, or on making any more significant changes to how the public API of bitflags works.

from bitflags.

The case of having two versions of that trait was exactly what I needed to avoid here because that would have required you to then issue a major breaking version of your own code. So on balance, I took a route that allowed us to evolve that trait without triggering widespread incompatibility.

Thanks for letting us know, and for sharing your reasoning around these changes.

I understand why this specific change happened this way, and I appreciate your quick response to this issue.

from bitflags.