Hi, I think we can just follow Datafusion's policy, which is a consumer and relatively conservative (4 minor versions, or ~6 month ) https://github.com/apache/datafusion?tab=readme-ov-file#rust-version-compatibility-policy
xxchan On Sat, Feb 22, 2025 at 04:21 Christian Thiel <christian.t.b...@gmail.com> wrote: > Dear both, > > Thanks for bringing this up! > As iceberg-rust is first and foremost a library crate (despite us > committing the Cargo.lock) I would try to not update too quickly. Three > months sounds reasonable to me. > We probably don't see most of the crate's consumers on crates.io, as they > are binaries. Forcing a rust update too soon is annoying for downstream > projects, as it typically requires changes on local machines and the CI. I > completely agree with Xuanwo that we shouldn't update if not required. > > Christian > > > On Fri, 21 Feb 2025 at 04:51, Xuanwo <xua...@apache.org> wrote: > >> Hi, renjie >> >> Thank you for bringing this up. >> >> Most of our users are currently using the latest stable or even nightly >> Rust, so MSRV itself is not a major concern at the moment. We can upgrade >> to Rust 1.85 (the first version to support Edition 2024!) today. >> >> However, if we do need to establish an MSRV policy, I think a three-month >> period (covering two Rust stable releases) would be reasonable. That said, >> I will phrase this as "at least three months," meaning we retain the >> flexibility to delay upgrading MSRV if it's not necessary. This way, we >> won't have to track and upgrade it every time a new version is released. >> >> On Fri, Feb 21, 2025, at 11:35, Renjie Liu wrote: >> >> Personally I prefer a longer gap(like three months) so that we don't need >> to force users to upgrade to the rust version. But this may not be a big >> problem in the rust world as rust's release is usually quite stable and >> backward compatible. >> >> On Fri, Feb 21, 2025 at 11:30 AM Renjie Liu <liurenjie2...@gmail.com> >> wrote: >> >> Hi: >> >> As discussed in this issue >> <https://github.com/apache/iceberg-rust/issues/440>, we have landed >> support for using unstable rust for tooling, while stable rust for >> publishing libraries. Also we enforced checking of msrv(minimum supported >> rust version) in our ci. However, there is one thing undetermined yet: how >> frequently should we upgrade msrv? Or the question is, as rust continues to >> release new versions, what's the gap between our msrv with the latest >> released rust version? >> >> Different projects have different policies, for example sqlx >> <https://github.com/launchbadge/sqlx/blob/main/FAQ.md#what-versions-of-rust-does-sqlx-support-what-is-sqlxs-msrv> >> uses >> a six week gap, while tokio >> <https://github.com/tokio-rs/tokio/blob/master/CONTRIBUTING.md#minimum-supported-rust-version-msrv> >> uses >> a six month gap. >> >> Different policies have different pros and cons. A short gap ensures that >> our library could use newer features/improvements in rust release, while it >> forces users to upgrade to newer rust versions. Longer gaps have opposite >> pros and cons. >> >> Looking forward to hearing your thoughts! >> >> Xuanwo >> >> https://xuanwo.io/ >> >>