Why so frequent semver-major breaks?

[kornelski]

It looks like bindgen users are not keeping up with the rate of semver-major changes. Almost all crates use an older version of bindgen, and currently 0.54 (3 major versions behind, 8 months old) is the most downloaded one.

Is it necessary to make so many breaking changes? Would it be possible to slow down semver-major breakages or maybe move unstable parts to a sub-crate?

[emilio]

Thanks for filing this.

Would it be possible to slow down semver-major breakages or maybe move unstable parts to a sub-crate?

Part of the issue is that I try to be extremely conservative about what considers a breaking version change.

Even things that change the generated code (maybe for correctness!) in a way such as code will potentially no longer compile, which would usually be a bugfix, I try to put them in a breaking release (because otherwise it's a matter of time people hit it and they file the opposite issue to this one).

For example, the latest release was breaking because 19142ac removed a public field from structs in some very unlikely edge cases. I believe the last few releases have been similar as well though I could double-check.

The layout of the struct was broken before, so maybe considering it a bugfix is not too bad? However I feel like stuff should generally not stop compiling. Not sure what the best answer here is, ideas definitely welcome.

[Lokathor]

Code that was bugged before should stop compiling when possible.

[kornelski]

I see the difficulty. I'm not sure what to recommend.

Maybe you could run something like crater runs to test whether edge cases are found in the wild?

Maybe you could provide methods/traits for hiding the hacky parts of bindgen like padding fields, ask people not to use __bindgen fields directly, so that they could change without breaking users?

Or maybe these changes could be hidden behind a config flag, and the old behaviors cleaned up in less frequent major releases.

[emilio]

Code that was bugged before should stop compiling when possible.

Sure, but there's also the case of code that was working before (even if by chance, and not being buggy) which we changed to fix and edge case which would be bogus.

Maybe you could provide methods/traits for hiding the hacky parts of bindgen like padding fields, ask people not to use __bindgen fields directly, so that they could change without breaking users?

Yeah, we could document that we expect to be allowed to change fields prefixed with an underscore at all times or something, but sometimes it's hard to avoid using those when constructing things...

Or maybe these changes could be hidden behind a config flag, and the old behaviors cleaned up in less frequent major releases.

That's the more reasonable path forward, but that's probably a fair share of maintenance burden in some cases... I'll try to do this more in the future, when possible.