Evolving Rust through Epochs

[zackw]

Perhaps we could borrow the versioning scheme used by the C and C++ standards: “Rust language specification, YEAR”. I think that would set the right expectations in terms of both the kind of changes expected and the continued availability of support for older specs.

I see that the RFC already uses years for the numbering scheme, so this is pretty much just a matter of terminology.

[leonardo]

Before discussing the details of Epochs management in this thread I think it’s essential to have an as much complete as possible list of things we wish to fix/change now in Rust that can’t be changed in the normal way. Then if the amount of the changes that can be done in the Epoch is too much small compared to the whole list, then the idea of Epoch could be redesigned.

I also think epochs don’t need to have a regular cadence, they should be more need-driven and irregularly spaced.

[NoamB]

I just looked at this thread (raw identifiers). If the solution that’s presented there is actually necessary, we probably want to prevent the spread of future-keyword-containing-identifiers before disallowing them in the language itself. Maybe crates.io could reject new crates if they trigger warnings about incompatibility with future epochs?

[mgeisler]

using new major versions, and having rustc commit to supporting code written for previous major versions of the language as well.

This is not what most people think of as major versions, though.

I’m not sure… it’s what I would expect from most tools That is, version X of the tool should be able to work with files in format X, but also in all previous versions. For a tool like a compiler, I would say it’s particularly important to keep compatibility so you can compile your 5 or 15 year old source code with a current compiler.

As I read it, this is basically also what the epoch proposal says: you can keep your code on epoch 2015 and still expect it to compile with newer compilers. So whatever new features epochs 2018, 2020, etc will bring, the compilers will keep the support for epoch 2015.

[blucell]

Isn’t using years as an epoch will be forcing us to push as many changes as possible at one release? and changes that did not make it into this one will be forced to be delayed until the next year?

I suggest using target rust version as epoch, as it will be more flexible, and it may be confusing to have multiple incompatible versioning, and because of that rust versions will not be communicating incompatibility, but the catch is that it may be communicating seamless upgradability, too, which may not be the case.

[skade]

My understanding of the epoch system is they do provide seamless upgradability, because you need to opt into the next epoch.

This merits having two versions.

For example, Rust 1.123.0 might support both compiling epoch 2015 and epoch 2018 code. All code written since 1.0 will be 2015, unless explicitly opting in to 2018. It might generate some warnings for things that might be incompatible in the future.

[blucell]

What I mean by seamless upgradability is that when I write code against Rust 1.0, I expect it to compile using Rust 1.23 without changing it, but I won’t expect a code written against 2015 epoch to compile against 2018 without rewriting.

The point I am concerned about is that using year-based epoch may not end as flexible as other versioning techniques can be, and this was just a suggestion. Another one that comes to my mind is using year-month epoch instead.

[steveklabnik]

I suggest using target rust version as epoch, as it will be more flexible

A target version is inflexible, as each target version has one specific day on which it’s released. A year, on the other hand, has many releases. A year is much more flexible than a specific release.

[johnthagen]

The point I am concerned about is that using year-based epoch may not end as flexible as other versioning techniques can be

C++ uses years, but it’s labeled after it’s released, so I don’t think they are technically limited to “this needs to all get in by year X”, even though it does seem like ever since C++11 they are on a 3 year cadence.

An example of this is that C++11 was originally expected to come out before 2010, hence the C++0x name, but slipped to 2011.

I guess my point is that as long as you don’t need to release two epochs in the same year, having a year-named epochs that are tagged when the epoch is released seem just as flexible.

[zackw]

Isn’t using years as an epoch will be forcing us to push as many changes as possible at one release? and changes that did not make it into this one will be forced to be delayed until the next year?

Epochs should only be happening at intervals considerably longer than a year. C++ is doing something very similar at three-year intervals, and that’s still too fast, they’re talking about C++20 already and I don’t even think I have a fully C++11-compliant compiler+library on this computer! I’m actually inclined to doubt a fully C++11-compliant compiler+library exists! The right cadence for epochs is something like once a decade.

Yes, that means some changes have to wait a very long time to get done. That’s a Good Thing for everyone trying to use the language, it means it’s a stable foundation.

But most changes don’t need an epoch. Even huge stuff like NLL doesn’t need one, as I currently understand it anyway.

[Centril]

Sometimes, the need for epochs is caused by things that are improbable to mess with more than a tiny fraction of the ecosystem’s code, an example would be making if let true = p && q bind as if (let true = p) && q - for that example, there are zero usages in crates.io, but it is a breaking change. These things can be easily fixed by a rustfix tool that lets you transition between epochs without any manual labour. That could entail that the three year interval is too long rather than too short.

[Ixrec]

Although it’s impossible to prove any of this, during the Great Epoch Debate of 2017 I quickly formed the opinion that:

1. the list of “epoch-worthy changes” we currently know about is very small (i.e., single digits), so probably all of them will be in the next epoch
2. it’s extremely unlikely that we’re going to discover any additional epoch-worthy changes with the current feature set of Rust

Therefore:

3. we won’t know what, if any, additional epoch-worthy changes there are until we stabilize new features

So my opinion on the proper epoch-as-breaking-change-batch cadence is simply: There isn’t one. It’s entirely possible we don’t discover any epoch-worthy changes for a decade or more. Maybe we already fixed them all. Or maybe something terrible will happen the day stable specialization ships and we’ll “need” an epoch next year.

Of course, epoch-as-marketing-nexus cadence is an entirely different subject, so we may end up doing a regular cadence without having any breaking changes to ship in most epochs. In fact, that’d probably be the ideal outcome.

[zackw]

epoch-as-marketing-nexus cadence is an entirely different subject, so we may end up doing a regular cadence without having any breaking changes to ship in most epochs. In fact, that’d probably be the ideal outcome.

I would consider that to be an extremely bad outcome. If there are no breaking changes then there should not be a new epoch, period.

[rpjohnst]

Even with no breaking changes there will still be a lot of non-breaking, idiom-changing changes, at least if the current epoch is anything to go by. That’s enough to warrant some kind of major marketing push, even if it’s distinct from the breaking-changes marker.

[zackw]

I don’t really believe in marketing in the first place, but leave that alone for now.

It is really, really important to have a marker that is reserved for breaking changes, that will never be used for anything else. If epochs are for opting into breaking changes, then epochs must never be used for anything other than to define a set of breaking changes. It’s a trust thing. We’re promising that (to first order) if you set epoch = 2018 in your Cargo.toml you won’t get broken by any changes after the 2018 epoch is declared. We are also promising that you will not need to change that number until you want to opt into the new features that actually call for the breaking changes. Both promises are essential. Tying anything other than a breaking change to a higher epoch is a violation of the second promise.

[Ixrec]

I’m actually with you on that idea (that breaking changes and marketing should not be conflated into a single “epochs” concept) but my understanding was that we already lost that battle and that simply is what “epochs” mean now.

[zackw]

Epochs haven’t happened yet (I think?), so it is not too late to revise the policy.

If epochs are a marketing version number, then there is no point at all to them; we already have the compiler version number that increments on a steady schedule regardless of how big or small the changes in that cycle may be. "Major marketing push"es can be, and indeed already are, tied to that. They don’t need a number, they can just be “look at all the cool new stuff since the last time we told you about all the cool new stuff”.

[elszben]

I agree with this reasoning, the compiler/language(?) already has a version number, why do we need one more?

[glaebhoerl]

@zackw Whether they have merit or not, you are rehashing arguments that were debated extensively on the GitHub thread for the epochs RFC.

[steveklabnik]

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