Closed MarijnS95 closed 5 months ago
Thank you for taking the time to explain this issue. Yes, as you found out, the reason for this (rather annoying) version bound is indeed to keep the MSRV low. (In fact, as low as the image
crate, which is one of the biggest dependants of this library). I think the reason we added the upper bound is that we wanted to avoid people upgrading dependencies a patch version and suddenly breaking what worked before. I don't remember why we didn't just go for a non-patch version bump in exrs. There was some discussion at the GitHub discussions page though (#217)
I didn't think we would have to keep it for this long, I expected to wait maybe a few months until we can remove it, but here we are now. I'm willing to do something about it at this point.
I'll have a look at the pr :)
I think the last state was this:
The last plan was to release a new major version of exr (1.8.0, not 2.0.0) that allows the newest version of half. But the benchmarks show a regression. Maybe we should just leave it as-is?
If I remember correctly, I ran the benchmarks again later, which showed indeed no regression, so I don't see a problem removing the bound and doing a minor release.
Consider this sample crate, which compiles:
The
half <2.3.0
bound introduced https://github.com/johannesvollmer/exrs/pull/213 (to work around https://github.com/starkat99/half-rs/issues/97) prevents this crate to be used with crates - e.g.re_log_types
fromrerun
- which depend onhalf ^2.3.1
. If theCargo.toml
sample above is bumped toexr 1.6.5
, those bounds are now incompatible according tocargo
:I don't see why
exr
needs to take a stake inhalf
's MSRV bump. If you wish to maintain a low MSRV based on minimal versions, I recommend leaving the semver-compatible upper bound open (^2.1.0
) and testing your MSRV with a fixedcargo update -p half --precise 2.1.0
orcargo +nightly -Zminimal-version generate-lockfile
in the CI.It looks like that was intended to be done in https://github.com/johannesvollmer/exrs/commit/42a92aa4cabde3cb0562712a251d21f161171a86 but that ended up reverted in https://github.com/johannesvollmer/exrs/commit/3d43e30a678b5c89a229d4e71ea4fca636378a17 without commit message, so I can only assume that at least
rust-version = "1.70.0"
broke building on Rust <1.69 even with the intended/documented workaround.