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

Make MSRV "whatever popular distros support" AKA "what oldest supported Firefox ESR requires" #3412

Closed
Kixunil opened this issue Jan 12, 2021 · 3 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request.

Comments

@Kixunil
Copy link

Kixunil commented Jan 12, 2021

Is your feature request related to a problem? Please describe.
As tokio reached 1.0, it is expected that users will become more confident in it and attempt to write (update) applications/libraries against it. Several crates already updated to support this version. However tokio having MSRV that's higher than what popular Linux distributions support will make it hard to package applications using tokio for these popular distributions. Because of importance and popularity of tokio it's expected that this will affect many projects.

Aside from issues around packaging applications, this also affects non-packaged applications as their users might prefer to use a compiler from signed trusted source (a repository) instead of piping curl to sh or laboriously verifying the fingerprints/signatures from a separate source.

Describe the solution you'd like
Declare MSRV to be "whatever most popular stable Linux distributions support but not newer than 6 months old". As @xfix well described the popular distros support oldest supported Firefox ESR and that implies supporting a version of Rustc required to compile it.
The list of considered distributions could be explicit. Ubuntu, Debian stable, Fedora should suffice I think.

Describe alternatives you've considered

  • Modify tokio 1.0 to support 1.41 (cosmetic changes so far) but don't promise to support it further. There's a chance that the new version of Firefox ESR will trigger update of rustc in popular distros. The problem may appear again but defer dealing with it when it occurs.
  • Add a clause "unless compiler feature(s) with huge benefits are available in newer version" to make it not hold back the tokio development
  • Instead of promising support, simply promise to accept well-formed PRs from volunteers who care enough to support older versions. The requirements can be specified somewhere. This should decrease the load on tokio maintainers.
  • Keep the policy as is. People who care can fork tokio, modify it to support older Rust and use [patch]. I consider this ugly, last-resort solution.

Additional context
I happen to be an author of several applications that intend to support Debian stable and use tokio and a contributor to one application that intends to support Debian stable and may use tokio in the future. So I primarily care about Debian stable but guess that users of other distros might be interested.

Edit: I just learned about standback crate. Perhaps its availability can be another argument for supporting older Rust versions.

@Kixunil Kixunil added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Jan 12, 2021
@Kixunil Kixunil mentioned this issue Jan 12, 2021
10 tasks
@taiki-e
Copy link
Member

taiki-e commented Jan 20, 2021

FYI, links to some distributions' rustc package and firefox's rust update policy:

@jaskij
Copy link

jaskij commented Dec 5, 2021

As someone using embedded Linux, I'll throw some extra info about Yocto/OpenEmbedded - one of the popular frameworks for building embedded Linux images and distributions.

  • Current LTS can be made to support 1.49 and 1.51 through an external layer
  • Latest release supports 1.54 in core
  • Releases are on a half year cadence April and October and will probably use latest stable, to within one or two minors
  • There's an upcoming LTS in April
  • LTS support is two years minimum

@taiki-e
Copy link
Member

taiki-e commented Aug 14, 2022

Closing per #4585 (comment).

Since upstream does not support this policy, it is not feasible to support this on our part at this time. If the situation changes in the future to make it feasible, we can revisit this.

@taiki-e taiki-e closed this as not planned Won't fix, can't repro, duplicate, stale Aug 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request.
Projects
None yet
Development

No branches or pull requests

3 participants