OpenDAL Usage based MSRV Strategy

[Xuanwo]

Hello everyone, following the discussion at Which version of MSRV should be next?. I want to propose the usage based OpenDAL MSRV Strategy.

Summary

• All libraries released by the OpenDAL project will adopt the latest version that can covering approximately 90% of users as MSRV.
• All binaries released by the OpenDAL project will always use the latest version.

Data is gathered by crates.io requests based on cargo version for the "Past 1 Month".

Context

OpenDAL has an MSRV but hasn't established a strategy yet. It's important to have a clear MSRV policy so our downstream users will know when OpenDAL will update its MSRV.

This policy should be predictable and meaningful. It's not effective to just choose a hardcoded version of Rust to support, as versions are not equally used. Some Rust versions have more users than others. For example, Rust 1.75 has 2.83% of requests, while 1.76 only has 1.78%. The reasons are complex, determined by the features this version includes and major crates' MSRV.

Proposal

Instead, I proposed a usage-based MSRV strategy: we choose a percentage we can support, then select the closest version to this percentage as our MSRV.

The data source is crates.io requests based on cargo version, for example:

We can generate a collection of projects based on versions:

• 1.82: 13.56%
• 1.81: 66.73%
• 1.80: 76.79%
• 1.79: 83.03%
• 1.78: 86.44%
• 1.77: 88.04%
• 1.76: 89.83%
• 1.75: 92.75% (our current MSRV)

If we choose 1.76 as our MSRV, 89.83% of cargo users can use opendal without increasing the MSRV.

This evaluation will occur every time we plan a minor version, even after our v1.0 release. The release manager will follow the same process described here to select the MSRV and include it in our release vote process.

---

What do you think?

[koushiro]

How about using the data from crates.io requests based on cargo version for the past 3 months?

Because the Rust toolchain typically releases a new version about every 6 weeks 👀

[Xuanwo]

Seems a good idea to me. I'm ok to use last 3 months as data source instead.

[Xuanwo]

If we take the last 3 months data:

1. 1.84.0-nightly: 90.48M reqs, 0.67% (cumulative: 0.67%)
2. 1.83.0-nightly: 296.39M reqs, 2.18% (cumulative: 2.85%)
3. 1.82.0: 524.23M reqs, 3.85% (cumulative: 6.70%)
4. 1.82.0-nightly: 357.26M reqs, 2.63% (cumulative: 9.33%)
5. 1.81.0: 3.98G reqs, 29.26% (cumulative: 38.59%)
6. 1.81.0-nightly: 196.65M reqs, 1.45% (cumulative: 40.04%)
7. 1.80.1: 2.13G reqs, 15.64% (cumulative: 55.68%)
8. 1.80.0: 813.28M reqs, 5.98% (cumulative: 61.66%)
9. 1.80.0-nightly: 379.78M reqs, 2.79% (cumulative: 64.45%)
10. 1.79.0: 888.47M reqs, 6.53% (cumulative: 70.98%)
11. 1.78.0: 548.53M reqs, 4.03% (cumulative: 75.01%)
12. 1.77.2: 857.46M reqs, 6.30% (cumulative: 81.31%)
13. 1.77.0: 359.06M reqs, 2.64% (cumulative: 83.95%)
14. 1.76.0: 464.99M reqs, 3.42% (cumulative: 87.37%)
15. 1.75.0: 470.8M reqs, 3.46% (cumulative: 90.83%)
16. 1.74.1: 92.14M reqs, 0.68% (cumulative: 91.51%)
17. 1.70.0: 342.49M reqs, 2.52% (cumulative: 94.03%)