alercah
commented
6 years ago ==Confusion==
From a marketing point of view, we want to be able to say "Look at all this cool new stuff we've added since Rust 1.0!" Since Rust 2018 is the Big Release, we therefore say "Look at all the cool new things Rust 1.0 didn't have!" So far so good. Then a user looks at the docs, and they go "Wow, look at all these great features? I want Rust 2018!" They look at the upgrade instructions, and they say "In order to convert your code to Rust 2018..." and at that point we've lost them. They think that the new features are only available in Rust 2018.
That's no good. So we come at this from the other approach, we say "Everything in Rust 2018 is available in Rust 2015, except for a few features that aren't backwards compatible." They go, cool! That's super awesome that I can use all this new stuff! Then they look at the list of features, and they go "But wait, I remember the announcement when impl Trait came out a few months ago. And what about custom derives last year? Why is 2018 only being released now if all of its features were previously available?" And again, we've lost them.
This is all going to get worse when we start adding features after Rust 2018 is released. If Rust 1.33 is the one that releases Rust 2018 (I am not going to spend the time looking the schedule up, so I might be wrong), and we add a feature in 1.34, what edition is that feature in? Is it in 2015? 2018? 2021? We haven't even picked when the next edition will be! If members of the team are confused by this, you can bet that our userbase will be even more confused. Moreover, we say "This feature we just launched is part of Rust 2021.", people will expect that they can then put edition = 2021 into their Cargo.toml, and that's wrong.
Here's my analysis of this problem.
==Definitions==
The Rust language itself has promised to always maintain backwards compatibility since 1.0. Instead, it will use the addition of dialects in order to accomplish improvement by breaking change. In this post, "the Rust language" or simply "Rust" refer to this language encompassing many dialects.
An individual Rust dialect is an actual specification of a programming language used in interpreting a source file, and every crate only uses one dialect. The Rust language promises that the dialects will remain as close together as they can, without breaking their backwards-compatibility guarantees, and that code from one dialect will be interoperable with code from another (although it does not promise that there will not occasionally be some impedence mismatch in difficult cases). It also promises that conversion to a later dialect is an operation that can be performed mostly automatically. This interoperability promise is only within single versions of the language, however: there's no promise of interoperability between dialects in different language versions. The edition field in Cargo.toml selects the dialect for its crate.
==Versioning==
Rust has never broken backwards compatibility since 1.0, and the addition of new dialects does not violate this. Currently, there are no plans to break backwards compatibility, and plans only to continue using dialects to handle breaking changes. As a result, Rust as a language is currently only incrementing the minor version, and will continue to do so for some time.
Note that, conceptually, the language version and the rustc version are not the same. So far, they have been the same, but there is no inherent reason they need to be. rustc could introduce a breaking change to flag processing, for instance, which would require a major version bump, even though the language itself remains backwards compatible.
It's also worth noting that, theoretically, Rust may decide to drop support for an old dialect. This would necessitate a switch to 2.0. I'm not arguing for it; merely indicating it as a possibility and providing interpretation for what Rust 2.0 would really mean in this model. As with any other version, it's possible in theory that rustc could diverge on this.
Dialects, on the other hand, could have two effective versioning schemes. The first would be that they each get their own versioning model. Rust 1.0 had one dialect: 2015 1.0 (to use semver technology). Rust 1.32 (note: I may have the actual numbers off here; don't nitpick them!) may be the last 2015-only version with 2015 1.32. Then Rust 1.33 would contain both 2015 1.33 and 2018 1.0.
The other approach would be to treat them as different major version lines of the same product. In this approach, Rust 1.33 would have simply have Rust Dialects 1.33 and 2.0. The edition monikers are merely proxies for the major version number. I don't think it actually really makes a difference, so while the second model maybe is the more theoretically pure model, the former is slightly easier to write about.
==The Overloading==
Imagine we have a Gantt chart of dialect verisons. I am bad at making diagrams, but it looks kinda like this one:
https://assets.ubuntu.com/v1/f02f0a4b-r-eol-ubuntu-full-2018-02-28.png?w=800
On the left, we put "Rust 2015", "Rust 2018", as our dialects. We mark the position in time of each language release as a vertical line, cutting through the various dialects. Now, when we add a new edition, which way are we growing the chart? It intuitively looks like we should just add another dialect row, and have it start at some version, and keep extending rightward. This is growth vertically.
But rightward growth, the evolution of the language in gaining new features, is also part of the new edition. We're trying to use the term "edition" to describe two directions of growht at once, and it's not working.
==Possible Solutions==
I don't have a perfect, magical solution, especially given that we don't want to contradict the existing marketing too much or it will risk confusing people even more. My best idea is to stop using "edition" to refer to the dialects, and just call them "dialects", or go back to the "epoch" terminology only for the dialect (n.b. not a huge fan of this particular word), or find some other similar term. Then, rather than talking about the "release" of "Rust 2018 edition", we call can say that "Rust 2018 edition is complete in Rust 1.X, and with that the release of a new Rust 2018 dialect". Now "Rust 2018" is overloaded, but can be disambiguated. And we can start talking about new features being part of the "next edition", without implying that the next edition is already available as a language dialect.
There has been a bunch of discussion on Discord; the basic problem is that it's not clear what is 2015 and what is 2018. I'll write up my thoughts here coherently shortly.