2020 : Milestones?

Disclaimer: I am not in the Rust team, so I may make wrong assumptions.

I did not planned to do a 2020 post, since my wish list for 2020 was not especially creative:

  • Finish the 2019 roadmap
  • A cross-platform, native like, GUI library.

However, when I read the Nick Cameron's 2020 blog post, I thought about something that might be interesting about editions. One of the Nick's points was that a 2021 edition would be useful as a rallying point to highlight progress on “async”. I agree that a rallying point is desirable, but I believe the edition system is a terrible way to do that.

The problem with editions as rallying point :

The edition system was introduced with two orthogonal goals:

  • introduce features that break the compatibility at the source level, without breaking the ecosystem.
  • serve as milestone to advertise the overall Rust progress.

While the first goal is a huge success, the second goal seems a failure to me. What most people remember about the 2018 edition are the module system, the dyn keyword and a rushed website that most of the community considers as a regression. The edition system failed to bring to light most of the great improvements that happened in Rust since 2015.

The problem is that, when an edition come out, the whole set of changes since the release of the last edition has no concrete meaning, since nobody should be using this unsupported version anymore. The focus naturally goes to the breaking changes.

Another problem is the fixed schedule that does not match the usual Rust rolling release model where new features are not rushed and stay in nightly until they are ready and community approved. The new web site, revealed too late to consider feedback, was the most obvious example for the community , and according to some blog posts from the Rust teams, releasing the breaking changes on time caused stress on them too.

I think the edition system is great for language evolution, but it should be breaking changes focused and not time constrained. There is no reason to consider an edition if there is no breaking changes in the pipeline.

So how to advertise Rust progress ?

If we want to mark progress, we need something to introduce actual changes on a large period, and there is an often-requested feature that meet this need: LTS versions. However, LTS are usually released on a fixed schedule that may not be optimal to highlight the overall Rust progress. So I suggest a mechanism between the big releases and LTS, let's call it Milestone versions.

When we believe a particular Rust version is great to show off the Rust progress, we ship it as a Milestone version. Milestone versions would have a code name that help to advertise them, like Firefox Quantum helped advertise Firefox speed improvement. These versions would be supported at least 2 years or 3 month after the release of the next Milestone, whichever come last (numbers for illustrative purposes only). So there would be an actual changelog to display between two Milestones.

For instance (completely hypothetical timeline) :

  • Most of the async shortcoming are fixed in the version 1.44. We can release it as a Milestone version with a cool name like "Async is in the place, Milestone 1".
  • One years and a half later, Rust is able to use const everywhere you ever dream to, we could release another version as milestone: "Everything’s const, Milestone 2". Milestone 1 and Milestone 2, should be supported six month in parallel.
  • Three year later, Rust now support quantum computers, we release a "Rust Quantum, Milestone 3". The Milestone 2 support had to be extended for one year + 3 month.

With Milestones, you can advertise actual improvements between Milestone versions as well as introducing LTS, an expected feature for Rust adoption in production.

Long support drawbacks

While long period support is a feature often requested to be able to use Rust in production, it will require additional work. I have no idea of the actual weight of this additional charge.

Another risk would be that the user base would be split between Milestone users and stable users. But I believe the community is now large enough. I don't fear that stable users count would drop that much.

If the drawbacks of long term support are too strong, we may just keep the idea of Milestones with code names to advertise particular stable versions with no additional support.


Another problem is the fixed schedule that does not match the Rust philosophy: release when ready and community approved.

How is this Rust philosophy? Rust releases every six weeks. It is rather that time-based release is Rust philosophy.

1 Like

What I mean is that when something is not ready, it waits for the next release. This is not a problem with a six week cycle. AFAIK there is no target date for the features in nightly.

I updated the original post to be more explicit.


I don't know if I'll ever get around to writing a "Rust 2020" post myself, but I have been thinking that if we do a "rallying point" edition, it would make a lot more sense to wait until we have more of the in-progress features at least partially stabilized, like impl Trait in trait methods, specialization, const generics, CTFE, GATs, etc. Even for async/await, you need half of those other features to make async trait methods possible. I completely agree that the async/await MVP, as awesome as it is, doesn't feel like enough to motivate an edition to me.

Or perhaps more to the point: async/await MVP is already guaranteed to revolutionize Rust code. What would an edition add to that? It's still just one feature. If "rallying point" editions have value, presumably it's in the synthesis of several features being greater than the sum of its parts.


We should not edition or milestone on minimum output. We should wait until a change has sunk into the whole stdlib and made it practical to use without worrying about things like "oh is that method also const yet?"

I agree. But the big difference (and what I don't think was explained very well, but seems to be one on the points made), is that the past edition had a bunch of things rushing to get in. So while the normal releases are nice (oh, we missed 1.38 for async/await? the next release is only 6 weeks away), the edition release caused a lot of pain in that many things were trying to make the cutoff, and so had actual deadlines, as opposed to being stabilized because they had reached maturity.

Edit: Found a better way to express myself: Rust releases are time based, while feature releases are maturity based (e.g they go out in whatever release they're ready for). The 2018 edition was painful because it tied the two (time based and feature based) together.


I think this is the idea behind both the Nick's 2021 edition and my Milestone proposal. Both does not intend to celebrate the Rust 1.39 release, but when most of the known shortcoming will be resolved and most of the ecosystem will be ready.

Sorry, that was more to Ixrec. I saw "MVP" and got a little jumpy XD

Edited to add additional explanations and added a drawback section (it looks more like a pre RFC than a 2020 post)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.