Closed hoxxep closed 7 months ago
Not speaking to the value of this change but to the motivation:
I noticed that a patch version increment has caused other crates MSRV values to change, such as the zstd crate: https://github.com/gyscos/zstd-rs/issues/253
A change in MSRV in this crate does not affect the MSRV of any other crate unless they take an action like bump their version requirement. You can maintain a valid dependency tree for your MSRV via Cargo.lock
/ cargo update
. You can even use cargo +nightly generate-lockfile -Zmsrv-policy
. We are discussing stabilization on internals.
I agree in principle that the jobserver crate should be allowed to increase its MSRV, but might want to be careful about doing so.
On a rust 1.64 toolchain cargo update
is no longer able to resolve a valid dependency tree for the zstd crate. Currently, the only real option for end users on older toolchains is to manually search for and specify an older version of jobserver.
The reasons for submitting this PR are:
cargo update
is currently unable to do MSRV-aware dependency resolution.@epage I see you're contributing to the issue on MSRV-aware dependency resolution at https://github.com/rust-lang/cargo/issues/9930. My two cents would be that MSRV bumps could require at least a minor version bump, so that older toolchains can still benefit from bug and/or security patches in the future.
MSRV bumps are generally recognized as non-breaking.
From a tooling perspective, minor and patch are equivalent.
Also, a 1 year old MSRV covers 99% of requests to crates.io.
@epage I've copied our discussion into your internals thread since it seemed a better place to discuss than this PR 😊 https://internals.rust-lang.org/t/pre-rfc-msrv-aware-resolver/19871/50
Agreed the current interpretation is that MSRV bumps are considered non-breaking. They clearly are breaking for some users though, and so perhaps alongside the MSRV aware RFC we could change the precedent to consider them "semi-breaking" changes. An MSRV bump doesn't require a major version bump, but crates could benefit by leaving room in the versioning scheme to have the option to release patches on the old MSRV for security fixes.
Regarding the crates.io request metrics, I don't doubt the rust community is more up to date than C++ users, but I'd note that legacy/enterprise users will often have their own crates.io mirrors and forked repositories. So crates.io metrics could be skewed in favour of smaller non-legacy projects.
I noticed that a patch version increment has caused other crates MSRV values to change, such as the zstd crate: https://github.com/gyscos/zstd-rs/issues/253
This MR changes the RawFd type to one present in older versions of rust, so that the MSRV can be reduced to 1.63.
My understanding is that this type should be equivalent because it's gated against
#[cfg(unix)]
, and so the benefits ofstd::os::fd::RawFd
also supporting WASM is negated. https://github.com/rust-lang/rust/issues/98699In theory the MSRV of the crate library is 1.60, but there are dev-dependencies that require 1.63 which would break the MSRV testing workflow (rustix, required by tempfile).
If we insist on keeping the usage of
std::os::fd::RawFd
, I can feed back to the zstd crate and ask them to bump their MSRV instead. Thank you!