Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine MSRV Policy #239

Open
yuri-rs opened this issue Feb 16, 2023 · 4 comments
Open

Determine MSRV Policy #239

yuri-rs opened this issue Feb 16, 2023 · 4 comments

Comments

@yuri-rs
Copy link

yuri-rs commented Feb 16, 2023

I see that current master require 1.65 for 1 let...else statement and 1.64 for few std::future::poll_fn usages.
I don't think it is great, since these are too fresh Rust versions.
Also it would be good to provide clear MSRV guarantees in Readme and include this MSRV in CI.

@yuri-rs
Copy link
Author

yuri-rs commented Feb 16, 2023

I think it would be better to revert f6cb0ed at least for the next release

@Noah-Kennedy
Copy link
Contributor

We don't plan on having an MSRV policy right now. This project is pretty early on in its lifecycle and very much not stable yet, so we don't plan on having an MSRV policy until later.

What is the reason that you need a lower MSRV? 1.65 is not very new, given that rust 1.67 is currently the latest one out.

@yuri-rs
Copy link
Author

yuri-rs commented Feb 21, 2023

Ok, I see that there is no MSRV policy right now. Just expected some and expected some policy to be aligned with tokio somehow someday.

I, personally, think that MSRV not thought out in general, because it is quite common to just bump MSRV in the project without any indication.
For example, projects with tokio-uring = "0.4.0" dep will not compile on ubuntu-22.04 by rustc right after tokio-uring 0.5.0 with MSRV 1.65 release.

This result in situations like - tokio-rs/tokio#5048
By the way, I don't fully understand why the solution was to copy OneCell into the tokio, rather than specify once_cell = "=1.5.2" in Cargo.

I created this issue because:

  • would like to understand MSRV -- understood, no MSRV policy
  • feel that having MSRV policy (at least specify MSRV) is good

@Noah-Kennedy
Copy link
Contributor

I think that at least specifying the current MSRV would be good.

@Noah-Kennedy Noah-Kennedy changed the title What would be the MSRV for the next release? Determine MSRV Policy Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants