This is true, but is artificial pain. Lock files means this is a waste of effort. Lock files contain cryptographic hashes, so you could pull directly from crates.io without any additional risk to supply chain attacks. You would still need to verify the code in those packages, but it seems like a tool such as cargo-crev would be much more suitable for that.
Depending on what your actual issue with crates.io is you have some options:
Uptime/availability/reliability: is your system really more reliable? Really? OK sure, locally mirror all dependencies you need then. You could write automation for that.
Privacy (don't download from third parties): The mirror suggestion in the previous point solves this too.
Because the policy says so: Well, change that policy then. It is outdated.
Every library should be a separate package: Why? Rust uses static linking anyway. So you would need to package the source code anyway. But if you are determined to do this, make a tool to do it for you instead of doing it by hand like it sounds like you are doing. Automation is king (see the previous Let's Encrypt discussion).
Those are the only remotely reasonable objections I could think of. I'm interested to hear reasons why you disagree.
From the Linux kernel point of view, after speaking with a few stakeholders, a Rust LTS could benefit some kernel users, thus it is likely we would want to support it eventually.
However, we would also very likely need to keep support for the latest Rust release (as we do now), for other users, among other reasons. We probably want to avoid that until we can at least reduce more the list of unstable features and/or drop our custom alloc fork.
Nevertheless, we would like to be in the loop about the Rust LTS.
Hey all! Speaking with my Ferrocene hat, we are happy with Rust's release cadence, and we wouldn't benefit much (if at all) from an LTS channel maintained by upstream. We should not be a motivation for LTS releases.
For the record, we're constantly improving our automation to reduce the workload for each qualification, and we plan to increase our release cadence to more than one qualified Ferrocene release a year. This will most likely not match with the release schedule of other commercial providers, as each company will have its own internal planning and scheduling.
Also, I expect "what should go into an LTS branch" to be fairly controversial, as each use case has a different risk profile. I could see a large web company wanting to backport large performance increases (as that could result in non-trivial monetary savings), while on safety critical even some security and unsoundness fixes might not be backported (for example if they don't affect the targets we support).
Companies with paid staff are not the only beneficiaries of a LTS. Think about packaging applications for a Linux distro (eg. Debian), and backporting newer app releases to the stable distro release: that's typically work done by unpaid volunteers, who would benefit from the stable distro being able to ship a LTS toolchain, and the ecosystem supporting the LTS. Without those 2 conditions, backports to stable distro has to depend on getting the toolchain backported, in addition to dependencies (and toolchain packaging is really not trivial work, which I think does already gives work to unpaid volunteers).
Let's check with Linux distribution Rust maintainers (the actual Rust package maintainers, not just those with general opinions aligned with Linux distributions) in order to find out requirements they'd have that might be assisted by an LTS.
Note that an LTS for a distribution would only help the distribution if the ecosystem adopted the LTS, and in particular the packages the distribution needs to package and update in their stable distribution use only the LTS. For instance, if Firefox or (in the future) the Linux kernel uses features beyond the LTS.
You have mostly just given a list of reasons why rolling release (or at least frequent releases) is better. I don't think that was your intention though.
Arch Linux (definitely far on the rolling side of things) has been way more stable on desktop for me than Debian or Ubuntu ever was. And they seem to have no problems wirh updating to new Rust versions within a few days of the new upstream release.
Perhaps there is a place for a distro that is like rust, not rolling, but releases often. Something like every 2 months. Maybe this exists (haven't really been interested in anything except rolling release). But I think it would bring the best of both worlds to users who don't want to be the first to hit bugs in software (it has happened on arch, but the bugs are fixed quickly, unlike on debĂan or Ubuntu where they usually aren't until the next major version).
I'm digressing but arch is already what you are looking for unless you use the developpement channels (or whatever they are called) since most updates sits for a few days or weeks before being pushed to users.
Sounds like Debian testing. (That's a rolling release distro, have been using it for about a decade now.)
Distro bikesheds aside -- IIRC for Fedora / Red Hat the situation is that they actually ship every other Rust release or something like that, isn't it? I seem to recall reading that, many years ago. Not sure if it changed. But anyway, the point is that having distros ship long outdated Rust versions that are unsupported upstream is not great -- but I am not sure if it's Rust that has to change here; one could also take the stance that distros are making unreasonable requests on their upstream packages here.
I'm a member of the Debian Rust packaging team, and have been (mostly) taking care of the toolchain packaging there for the past few years. Thanks @yann for dropping the pointer in our IRC room, I only randomly read internals when bug triage leads me here..
There are a couple angles that might make upstream LTS rust toolchains interesting for us on the Debian side, in no particular order (note that some of those would require buy-in from other Debian teams/maintainers as well):
Settling on a version for Debian stable releases (right now, this happens to be whichever version was in unstable at the time of the toolchain freeze, followed by a longer period with just bug fixes before the Debian stable release is cut), the main benefit probably being easier roll-out of security fixes if those are provided by upstream.
If crate developers caring about distro usage (and the major crate consumers which are relevant for distros - which would be firefox/chromium/gnome atm IMHO) settled on LTS as MSRV, the need for special toolchain backports that are done now (to support the browser packages) would be gone, and it might make security updates for such crates easier as well. As a side-effect, more software could be cargo installed using a distro rustc/cargo instead of upstream ones installed via rustup/..
If LTS-to-LTS bootstrapping is supported upstream, we could only package LTS releases (instead of every release one after the other, like we do now), but that woud depend on
how widespread the adoption of LTS-as-MSRV is (else this would hinder updating other software with a higher MSRV)
how frequent those updates are (if they are not often enough, we'd likely need to do more backporting/cherry-picking of fixes/.. which might outweigh the LTS approach)
All that being said, there are other blockers on the Debian side atm for proper security support for Rust packages outside of the browsers that just having an LTS release wouldn't solve. I do hope we manage to make some progress on that end during this release cycle, but we'll have to see.
We do atm see the Rust packages as mainly intended for packaging (applications or cdylibs written in Rust), not for end-users (of the toolchain/packaged crate sources) or for development of Rust code. If a Rust toolchain LTS release materializes and gets more buyin from the wider ecosystem, then using at least the toolchain packages for development would be easily doable (within the limits of using an LTS toolchain, of course).
Fedora ships every Rust release, updated on all active Fedora branches -- e.g. we have 1.77.2 on the current stable Fedora 38 and 39, beta Fedora 40, and Fedora rawhide.
On RHEL, Rust is a "rolling appstream" component that updates on every minor release. That's about 6 months apart, so it's a 4 or 5 step jump in Rust versions each time. The release pipeline adds some delay too, so the updates are not the absolute latest when they come out -- e.g. we'll have 1.75.0 when RHEL 8.10 and 9.4 are released in the next few weeks.
Quick note since you linked the changelog file -- that's an exported snapshot of what used to be in the %changelog section within rust.spec. I just recently transitioned to rpmautospec%autochangelog, so further entries are now drawn from the git commit messages.
This is problematic, as it would slow down the ecosystem, having users demand that crates work on those old versions. The rust ecosystem overall wants to move much faster than Debian.
You seem to be confirming my worst suspicions here.
I think requesting that would be entirely unreasonable, especially for LTSes similar to Debians releases (every few years!). If it was two LTSes per year (with a half year support window) this could be somewhat acceptable.
Taking the discussion in a slightly different direction; is there work that can be done without a formal LTS toolchain that would lay the groundwork for a useful LTS to exist?
My feeling is that there are two significant lumps of work that can be done to lay the groundwork for an LTS:
Get a significant subset of the ecosystem (all the crates that distros need, for a start) to agree on MSRVs that match up to the proposed LTS versions; if there's general agreement on MSRVs of 1.70, 1.80, 1.90, 1.100 etc, then it's clear that these versions are good candidates for LTSes. On the other hand, if every release could be a chosen MSRV for some significant crate, there's no clarity here.
Do the work to make it possible to build the next LTS candidate toolchain with the previous one; if 1.80 is agreed to be a good LTS candidate, with the intent to move onto 1.90 when that comes out, then it's helpful if I can use 1.80 to build 1.90 when it's released.
With those chunks of work done (and I do not think either chunk is either small, easy or trivial), we would have a strong basis in place for working on actually having a real LTS; we would know that crates are willing to hold back their MSRV to support an LTS initiative, and we would have people who are interested in LTS support who have experience working on the toolchain (because they've done the work to ensure that even though 1.81 through 1.89 - for example - can only be bootstrapped by the previous version, 1.90 can be bootstrapped by 1.80), which would hopefully translate into people willing to do the backports to have a 1.90.xxx LTS version.
It would be nice to allow skipping releases when bootstrapping IMO, but I think it will take quite a while before that becomes feasible unfortunately. Currently the in-tree standard library gets built both by the bootstrap compiler and the newly compiled compiler. Given how much the standard library is tied to compiler internals, even just supporting rustc N-1 in addition to rustc N is a burden. Let alone supporting several rustc versions back. There is a proposal to avoid building the in-tree standard library with the bootstrap compiler and instead use the standard library shipped with the bootstrap compiler, but that will likely take a while before that gets done. And even with that obstacle taken away, rustc itself depends on a fair amount of unstable features (often intentionally for dogfooding, sometimes for historic reasons or because there is no stable alternative) which makes supporting multiple bootstrap compiler versions harder.
Targeting 1.71+ (released 9 months ago), you support 90% of crates.io requests. 1.69+ (released a year ago), you support 96%.
Note that if a blessed LTS Rust existed, those numbers would likely change.
To add to bjorn3's points, we'd have to change our "new feature testing" approach, somehow getting more people to use nightly and opting into these. Right now rustc heavily dogfoods features that have an implementation but might or might not yet be ready for production usage. let-chains is one example, which we've been using for ages, to big success. This allows those features to get real-world usage in a controlled environment where the users' and the feature's maintainers end up generally being the same people. Having LTS rustc would mean scrapping that.
If we make MSRV testing easier, that will help. RFC #3537 is targeting Edition 2024.
The next step in the process is to deal with the conflict between the needs of users on new Rust vs old Rust. For example, a lot of people asked for an MSRV bump of env_logger to improve their build times by dropping is-terminal dep (which can take a long time to build due to dependencies). cfg_accessible would help a lot. We can emulate it with MSRV-aware resolver but it will take some care to get it right.
That won't cover every case, like using cargo features. The Cargo team has been more proactive into identifying what features should not require an MSRV bump which will help.
Those steps should make it a lot easier for the ecosystem to settle on a "every 5 versions" or "every 10 versions" MSRV. For myself, I'm also considering supporting more LTS of my packages so I can bump my MSRV but I still provide support for the previous versions with an older MSRV.
I'm thinking about this from the other direction; if you believe a blessed LTS is desirable (even if most developers are currently sticking to latest stable), getting the ecosystem on-board with sticking to MSRVs of the versions that you would choose as blessed LTSes is a necessary first step to having a useful blessed LTS.
If, for example, Tokio chose to raise its MSRV more frequently than the proposed LTS versions, or raised it beyond the most recent proposed LTS version, then you know that your proposed LTS is likely to be of limited use; if the ecosystem in general is happy to keep their MSRVs down to your proposed LTS versions, then that's signal that this is a workable idea.
Part of my intent here is to get people who want an LTS to assess how big a deal this actually is in terms of code; given that 1.80 and 1.90 are LTSes, how hard is it during the 1.90 development cycle to come up with a patch you can apply on top of the 1.90 release codebase that means that you can build it with 1.80 as well as (or instead of) 1.89? Is that patch huge and intrusive (my personal guess), or is it small enough that you could actually do it with conditional compilation?
My expectation is that the challenge factor in working out how to make 1.80 build 1.90, given that the developers of 1.81 through 1.89 have used new unstable features and updated to recent changes to unstable features, is comparable to the challenge of working out how to backport fixes from 1.81 through 1.90 to a 1.80.x release. If making the previous LTS build the next one is "too hard", then backporting fixes is also likely to be "too hard", and thus the LTS idea falls over because you can't backport fixes.
That won't happen if there is an official LTS. In fact it will have the opposite effect where even using the latest and greatest from stable won't happen any more. It will lead to stagnation in the ecosystem over all.
This is definitely a risk. We would need a good story for using new features while maintaining an LTS, whether that is having an LTS for your package or changes to make it easier to support both at once in the same package.
(That's a rolling release distro, have been using it for about a decade now.)