Evolving Rust through Epochs

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.

2 Likes

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.

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.

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.

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”.

5 Likes

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

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

4 Likes

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