In writing up the 2018 roadmap blog post draft, some of the writing led me to consider “era” as an alternative to “epoch”. While they’re considered synonyms, they have a distinct flavor for native speakers:
Era feels a bit less like a “strong break”, and more like the natural passage of time and evolution. In particular, it feels natural to talk about the “Rust 2015 era” when referring to how code was written shortly after 1.0.
In addition, era doesn’t suffer from the pronounciation issues we’ve hit with “epoch”, and overall has a friendly and more approachable flavor.
The blog post is now expected to go out on Monday, and we need to settle the question before then. At the moment, the core team pretty strongly leans toward “era”, and anecdotal data from folks not deeply steeped in the Rust community suggests that “era” feels more approachable. OTOH, at least at the moment, “epoch” is winning @carols10cents’s highly scientific Twitter poll.
The core team is interested in getting feedback before Monday. Please do not use the thread to re-litigate the concept of epochs or the versioning strategy, but stay focused on the immediate bikeshed.
Outside of geology, I think “epoch” is more often used to refer to a single point in time, whereas “era” is always an extended period of time. So that would be an argument for “era”.
I can’t resist proposing “edition” as a third alternative. The standards for standardized languages have editions, identified by year of publication.
Era sound a bit better as a non native english speaker. It is not ideal as it feels a bit ancient (in french, the corresponding word is). But epoch feels completely weird and has no meaning for me.
Seeing as how the Twitter poll has almost completely opposite results, I think your written justification for Era may have primed the people voting here.
In software often people use the words “version”, revisions, etc, So I like “Rust version 1” for the first era, “Rust version 2” for the second, etc. So now we’re in Rust V. 1.24.1, later we’ll be in Rust V 2.0, etc
To re-iterate: we're not going to re-raise the question of versioning scheme (years versus numeric versions), which was discussed in enormous length in the epochs RFC. The question is just how to refer to the scheme we arrived at.
I agree with @jethrogb that eventually we’ll move away from talking about this concept at all, and just talk about the years of the epoch/era/whatever releases - Rust 2015, Rust 2019. As much as possible I’d like to avoid this terminology showing up in the interface of rustc and cargo.
So whatever terminology we choose, we should prioritize the messaging we want to send now, while we’re explaining the concept, rather than worrying about the long term implications of what terminology we choose. Eventually this will just be a second nature part of how Rust development works (unless it goes unexpectedly terribly, in which case it will never happen again, so same outcome ).
I’ve definitely seen attempts to explain this to outside users which stumble over the current terminology. What we want to get across is that this isn’t a breaking change, and even after saying that I see responses like “so an epoch is a breaking change that’s even more breaking than 2.0,” the exact opposite of our intent.
I’d also add that I like “edition” the best of the three names here, as it seems less like a reach for a metaphor. I also think we should heavily lean on the idea that what we’re doing is fundamentally the same as C++XX or Java 1.X.
It’s worth noting that Ecmascript uses “edition” as well, though technically “edition” refers to the edition of the specification which defines a language named something like “Ecmascript 2016”.
The proposed Rust epoch concept shares much with Ecmascript editions, in that the editions define a set of generally backwards-compatible features that arrive in browsers continuously. If a change is not backwards compatible, you have to opt in (for example with strict mode).
).