Crates.io version released with breaking change and does not match GitHub master version

On https://crates.io/crates/bindgen, the newest version is 0.49.3, while GitHub master (dbe5bab) shows 0.49.2. HEAD (ad0bf8e) points to a distinct commit with a version bump.

I noticed, because #1575 is a breaking change and is included in 0.49.3. Because this version is semver-compatibel, it is automatically upgraded to.

[emilio]

Hmm, so you're right, I somehow messed up that release, will jank. Looking at my reflog, I was at a local master branch, not up-to-date with upstream since I had merged a fix before, and my release script just failed to push to upstream.

Regarding #1575 being breaking, that's a bit discutible, I'm not sure if we're supposed to guarantee stability with rust-target=nightly, but I guess given we don't document it either way, it technically is, and since the release is broken anyhow, I may as well jank it and publish a breaking version.

Really sorry for the hassle, this is all my fault.

[emilio]

I'll put up the right tag for 0.49.3 either way in the upstream repo (it is https://github.com/emilio/rust-bindgen/releases/tag/v0.49.3).

[emilio]

(And of course I'll fix my crappy release script to error out when any of the commands fail instead of happily continuing to cargo publish, d'oh)

[emilio]

Sorry, I should fix up all my scripts to use set -o errexit -.-

[emilio]

Ok, everything should be in order now. The tag was already right (https://github.com/rust-lang/rust-bindgen/releases/tag/v0.49.3), it just failed to push to master because of the fix that had been merged in between.

I've yanked that version, and published v0.50.0 with that fix. I've fixed up my scripts so that this doesn't happen again, and for now I'll treat rust-target=nightly changes as breaking.

That being said, I think v0.49.3 shouldn't be semver-incompatible, even with rust-target=nightly, so maybe I shouldn't have yanked it. How is #1575 breaking? You need to explicitly opt-into it, don't you?

Or you meant #1581? I guess that actually could be semver-incompatible, technically... I didn't think at the time removing a default-feature-dependency that isn't used at all could break anything, but I guess it technically could if we specify any clap feature that you could opt-out. Is that the scenario you meant?

Thanks for the fix.

#1575 is definitively breaking. Look at this change: https://github.com/rust-lang/rust-bindgen/pull/1575/files#diff-567e947a8cc5ad306d3eff99dfb66cc9L2173
This changes a variant of the public enum EnumVariation. I noticed, because I was using it with https://docs.rs/bindgen/0.49.2/bindgen/struct.Builder.html#method.default_enum_style. See also the two docs.rs versions:
https://docs.rs/bindgen/0.49.2/bindgen/enum.EnumVariation.html#variant.Rust
https://docs.rs/bindgen/0.49.3/bindgen/enum.EnumVariation.html#variant.Rust

Not sure, why you are talking about nightly. I am on stable and this was breaking on stable.

Anyway, thanks again.

[emilio]

D'oh, I didn't realize that particular enum was part of the public API when reviewing that. Really sorry for the breakage.

[emilio]

(I was thinking about the feature itself, generating #[non_exhaustive], which is done only with rust-target=nightly, and only if you opt into it).

Thanks for clarifying it.