Requiring Rust 1.70.0 and changing backwards compatibility policy in a minor version bump seems a mistake #97
Comments
|
The original plan was a 3.0, however, technically the policy has never been a publicly documented policy, merely a self-imposed informal policy. Unfortunately that self-imposed policy was preventing performance improvements like using hardware intrinsics without major releases, improvements that didn't have any breaking API changes but which all users of crate would benefit from, and delaying me long delaying making needed releases. The problem is major releases cause a number of downstream dependency issues, including depedency duplication and incompatibilities across downstream crates using different major versons: see the futures 1.0 stabilization which was a very big pain across the crate ecosystem, despite lack of breaking changes. This is something that also happened to this crate with the 2.0 major release, which was why I was avoiding any MSRV changes in first place. But again, locking the major release to an MSRV prevented use of hardware performance improvements to implementations, which is very critical to the use cases of 16-bit floats these days. In general, the default crate ecosystem has settled on MSRV changes in minor updates not being breaking changes, with so many crates in ecosystem just assuming latest couple of rust compilers without even specifying MSRV. The changelogs were perhaps not properly worded, because it was mostly provided as a public notice for the MSRV change. With that in mind, and given the significant benefits that downstream users get from improved implementations (and after some urging directly from contributors), I decided it was best to change policy and do it without an essentially do-nothing major release. Finally, to go on a bit of a rant that I want to be clear is not directed at anyone but general frustration, the real solution to this is for the ecosystem to finally get the cargo MSRV resolver RFC done, which has been stalled for far too many years; the MSRV has long been marked in this crate's |
Two points of data from the Changelog:
and
Look, I can understand that this crate is probably depended upon by projects that have some anxiety about actually following semver to the letter, even if cargo is going to complain as-such if you don't. However, this change presents the following problem:
^MAJOR.MINOR.PATCHinstead of=MAJOR.MINOR.PATCH(assuming one just writes e.g.2.2.0that actually means^2.2.0instead of=2.2.0.imagecrate for example usesexrwith the following dependency on 0.24.6: https://github.com/image-rs/image/blob/v0.24.6/Cargo.toml#L47C10-L47C10. The latest version ofexr(untagged) uses^2.1.0https://github.com/johannesvollmer/exrs/blob/master/Cargo.toml#L31.exrandimagecrate which used to work now don't. You've broken your stated policy without a new major release, so if you're one of these crate maintainers, you have no way of knowing that a minor version bump is now imposing a rusc1.70.0 dependency across the board for both previously released versions and currently released versions.The first point above (requiring 1.70.0) isn't necessarily a problem. It's not even a problem for your project to make a requirement that a minor version bump may impose a new minimum version requirement. What is a problem is that you changed that policy (where previously maintainers would expect to see a major version bump if there's a new min-req) with a minor version bump, which negates the whole point of the thing.
My organization is wasting time on this at a higher level by using the
imagecrate. This isn't their fault, and it is something we can work around because we're able to relatively easily upgrade to a newerrustc. But it's completely unexpected and you're breaking every downstream crate by not making that policy explicit to crate maintainers who can opt into it (e.g. the maintainer of theexrcrate, @johannesvollmer).Can you please yank 2.3.0 and 2.3.1 and please focus on a 3.0 release with this breaking change for the future? This is only going to cause more chaos as people start to update and time goes on...
The text was updated successfully, but these errors were encountered: