As has been mentioned multiple times, this should be left to commercial suppliers. And to the best of my knowledge, you can buy this already Ferrocene - Ferrous Systems
If it's important to be available for free, talk with ferrous systems how much they want for that and find the users who want to pay for it and get them on a payment plan
BTW, Ferrocene is designed to be easier to update to keep up with upstream:
Currently it's 1.68. In the initial release they've commented they'll try to reduce amount of manual work, and aim to update the compiler twice a year.
Let's Encrypt has demonstrated that when people can choose how often they want to update certificates, they'll choose it to be as infrequent as possible (1-3 years), and keep it as a manual process, which is a chore and is error-prone. But when users are forced to update every 90 days, they will have to improve the tooling, automate the process, and then it becomes easy!
So I think Rust's frequent releases have some of this virtuous effect. To keep up, users have to change their practices, and rely more on automation, which then makes release frequency less of an issue.
This is an interesting suggestion, since it would presumably reduce the release team workload a bit, which could make room for the extra LTS workload. And it's not that much longer than 6 weeks that one would feel pressured to rush a feature into a release.
But it seems like generally a project-provided LTS isn't a clear win anyway... still, reducing the release cadence a bit could be considered independently of this. "There's a release the first of every even-numbered month" would be much easier to remember than the current schedule. 
I think we'd lose a lot if we crammed all new features into a single big release every 3 years. There's a lot of overlap between people working on different features, and it's much better to stretch out the work of pre-release and post-release polishing over time rather than having it all occur at once. (And there's always post-release polishing, the pre-release testing is never perfect.)
Also having a feature be done and then having to wait for 2 years before anyone can use it is quite frustrating, and barely missing the deadline for one of these big releases would be devastating. People would burn themselves out trying to get a feature done in time, features would be rushed and have more bugs than they need to. I don't think only having new features every 3 years is a sustainable development model in open-source.
One benefit of the current schedule is that it’s consistently the same weekday (Thursday). Weekdays even appear in the documentation of the release process.
If rust had LTS releases we should strongly encourage everyone to use the latest release for that LTS version and not support any older releases. That should be fine because there are as close to zero as possible breaking changes in LTS updates.
But we already have an LTS. It is called rust 1 and has been supported for ~9 years. We should encourage everyone to use the latest release.
It could just as well be the first Thursday of even-numbered months. In fact, 1.78 will be such on May 2nd, so we could easily start the new schedule from there.
(May isn’t quite even-numbered, I believe.)
I can attest that this isn't necessarily the outcome. Other outcomes that I have seen are sticking with "simple" error-prone manual renewal and switching to some provider other than Let's Encrypt.
(It is,if we were to use zero-indexing for months. )
Release in first week of January seems worse though (after Christmas + New Years), so 1-indexed even months might be better. As far as naturally coinciding occurrences go… well… we have some time until April and August of next year for that. Or we could celebrate 1.100 with the new release schedule.
| date | version | even month | first week |
|---|---|---|---|
| 2024-02-08 | 1.76 | ✓ | |
| 2024-03-21 | 1.77 | ||
| 2024-05-02 | 1.78 | ✓ | |
| 2024-06-13 | 1.79 | ✓ | |
| 2024-07-25 | 1.80 | ||
| 2024-09-05 | 1.81 | ✓ | |
| 2024-10-17 | 1.82 | ✓ | |
| 2024-11-28 | 1.83 | ||
| 2025-01-09 | 1.84 | ||
| 2025-02-20 | 1.85 | ✓ | |
| 2025-04-03 | 1.86 | ✓ | ✓ |
| 2025-05-15 | 1.87 | ||
| 2025-06-26 | 1.88 | ✓ | |
| 2025-08-07 | 1.89 | ✓ | ✓ |
| 2025-09-18 | 1.90 | ||
| 2025-10-30 | 1.91 | ✓ | |
| 2025-12-11 | 1.92 | ✓ | |
| 2026-01-22 | 1.93 | ||
| 2026-03-05 | 1.94 | ✓ | |
| 2026-04-16 | 1.95 | ✓ | |
| 2026-05-28 | 1.96 | ||
| 2026-07-09 | 1.97 | ||
| 2026-08-20 | 1.98 | ✓ | |
| 2026-10-01 | 1.99 | ✓ | ✓ |
| 2026-11-12 | 1.100 | ||
| 2026-12-24 | 1.101 | ✓ | |
| 2027-02-04 | 1.102 | ✓ | ✓ |
| 2027-03-18 | 1.103 | ||
| 2027-04-29 | 1.104 | ✓ | |
| 2027-06-10 | 1.105 | ✓ | |
| 2027-07-22 | 1.106 | ||
| 2027-09-02 | 1.107 | ✓ | |
| 2027-10-14 | 1.108 | ✓ | |
| 2027-11-25 | 1.109 |
Hah, indeed, I was too focused on the day alone. I like the zero-indexing excuse though.
We could nudge 1.80 into August if we wanted to start this in the near future.
Having thought about it some more...
If there were multiple downstream projects that want to maintain LTSes and those projects could agree on a cadence then it might make sense to provide a branch for them to which they can submit their patches rather than maintaining their own patchsets. The rust project itself wouldn't have to provide official builds of that branch. Perhaps some light CI testing (e.g. only linux, since we can dockerize the old cruft) to make sure it builds at all.
This would help avoiding the zlib situation where multiple distros maintained their own patchsets because there was no active upstream project for years. And I think it's what OpenJDK does for old versions, vendors can upstream their patches but it's up to them to provide their own builds.
This is the first suggestion that actually seems workable. It is not entirely free of costs though:
EDIT: Another point that someone made is that of Let's Encrypt before: make it easy to automate and stay up-to-date. Rather than making it easy to update manually very rarely.
6 posts were split to a new topic: Keeping Rust toolchain up to date with automatic reminders for available updates?
Sorry for dropping this thread for a week and a half, I unexpectedly had to go head down on one of my ongoing non-Rust projects.
I wanna drop in a bit of personal experience here. Right now, Guix is currently shipping rust 1.75, which is one version older than the latest stable. If you look at the change history for their rust toolchain packages, you'll see that they only update the toolchain once every five releases or so. This is partially because their process is manual and heavyweight, and partially because they've made an explicit decision to prioritize bootstrappability and reproducibility over currency. But it's also partially because, if you are determined to build an entire Linux distribution from source without allowing cargo or similar tools to pull in anything that isn't known to your own package manager, updating the Rust toolchain is a huge pain in the ass. I know this because I tried to do it myself last year, not even the whole toolchain just rust-analyzer (which was out of sync with the rest of the toolchain for months) and got buried under a cascading pile of updates to crate packages and gave up. Efraim Flashner seems to have figured out a more efficient process that doesn't involve patching a huge chunk of gnu/packages/crate*.scm on every update, but it's still clearly not efficient enough to keep up with the release cadence.
I think I have an idea for a way to change things on our end so that distributions like Guix and Nix have substantially less work to do to keep up to date, which should also address several of the other reasons why people might want an LTS toolchain. I'm going to start a new thread about that later today.
This is a fair point.
As things presently are, I think you're right, although I don't like it and I think it's not inherent to the open source model. Rather, the whole software industry has this expectation that everything happens as fast as possible, and so nobody learns the patience required to put up with waiting years for something to be released. This is not something that the Rust project can change by itself, but I nonetheless think Rust can and should set an example by progressively slowing down its cadence. I'm fully on board with "stretching our releases from 6 weeks to 2 months" as a first step.
I endorse @cuviper's suggestion that it could be the first Thursday of the month, and @steffahn's suggestion that it should be 1-indexed even months to avoid the first week of January.
This isn't just patience.
I previously linked to my post going into these details.
Would you still be on board if the rest of us only viewed it as a final step?
Something for us to keep in mind is that this would then have us run into Lunar New Year occasionally. The project is US / Europe-centric enough that it likely won't run into problems now but thought it still worth calling it.
The current 6-week cycle already hits holidays -- e.g. 1.49 was on New Year's Eve, and 1.83 will be on US Thanksgiving Day this year if we keep pace. We've never let that stop us, but it would be nice if the new strategy makes this less likely.
But the amount of changes is unrelated to the release frequency. The amount of changes will stay the same, so every update of Rust will continue to be a pain in the ass with a pile of updates.
In the amount of work needed, there’s no difference between guix updating their Rust every 2 months, and Rust slowing release cadence to every 2 months. You still have 2 months worth of changes to catch up to.
I suspect that this distinction between rate and cadency is often lost in the discussion, and many people who want Rust to release less often actually mean they want Rust to change less.
I think this is a tangent so I'll just say that I acknowledge the benefits you are talking about but I don't think they necessarily outweigh the benefits not having to update one's understanding of the language constantly.
For now. We can always have another conversation about this later.
It doesn't have to be this way, even if compiler updates (including new language features!) continue to come out on the same cadence they do now! That's what the new thread I mentioned is going to be about. Gimme an hour or so to finish writing.
If you want more after another conversation, I think that's a "no".