Rust 2018 release schedule and extended beta

[steveklabnik]

Hey all; we just published a broad overview of Rust 2018 over at the main Rust blog. I also wanted to share with you all some updates about the schedule and process by which we’ll be shipping Rust 2018.

Here’s an overview of the dates and versions:

Date	Beta channel	Stable channel	Status
2018-08-??	1.29	1.28	Nightly = “Edition Preview 2”
2018-09-13	1.30	1.29	Beta = “Edition RC 1”
2018-10-25	1.31	1.30	Beta = “Edition RC 2”
2018-12-06	1.32	1.31	Stable = “Edition release”

So, the initial version of Rust 2018 will ship in Rust 1.31 on December 6th. However, we’ve also decided to do an extended beta. With the normal release trains, the beta of 1.31 would ship on October 25th. But we want to get a little bit of extra eyes on the new features. As such, the plan is that on September 13th, for the 1.30 beta, we will produce a beta with the Rust 2018 features as stable. The stable release of 1.30, though, will revert the stability of these features, while they will continue to be enabled on beta until 1.31 is released. (See this comment by aaron for an additional clarification.) This is a bit of a break in our usual process, but we think it’s worth it to get the extended testing. We’d ask that when 1.29 ships, you consider giving 1.30.0-beta a try. The more people that use these betas, the more bugs we’ll be able to shake out before December.

As always, happy to answer any questions or elaborate on any more details.

[notriddle]

Why is it going with Rust 2018 released at the end of the year, instead of Rust 2019 released at the beginning of next year?

Rust 2018 is going to end up sounding like an old thing from last year three weeks after it comes out, which seems like mediocre marketing, when marketing is half the point of doing this.

[steveklabnik]

This is true for any year-based system; C++11 sounds old in 2013 too. A “Rust 2019” would only get you a bit farther; it’d sound old in 2020 and 2021. We can’t predict the future, but we can say “this is what Rust looks like at the end of 2018.”

[cuviper]

C++11 was optimistically called C++0x before its release… but if Rust 2018 does actually ship this year as planned, it will avoid that problem.

[aturon]

An small but important clarification: the features that are stabilized will ride the trains all the way to stable in 1.30. But the ability to opt in to the Edition will not.

That’s important, because starting with 1.30 it will be possible to migrate code to use the new features while leaving it in a state that can be compiled on either Edition. Thus, we can actually start migrating some stable libraries before the Edition is fully announced to the world.

[DorianListens]

I would tend to agree with the question about the naming. Since we’re planning to ship the new edition in December 2018, it might be wise for the marketing to refer to it as “Rust 2019” in order to get the most out of the push.

[dpc]

Agreed. Rust 2019 would seem brand new, shiny, trendy and cool for a whole year 2019. Rust 2018 will be like cars at the american car’s dealership, that sell at the discount because next year is already here. (I bought 2013 model car at the end of 2013 for this reason - trying to thrifty, and it was September, so people consider September a end of the year, and dealerships sell next-year models already)

I know it’s stupid, but that’s how human psychology works. And languages live or die by popularity. Anything that can catch an eye of developer and bring it to try Rust counts, multiplied by millions of potential developers.

With such a schedule, I think it’s still doable, fair and worth it to rename the edition to be 2019, and I think it’s a great idea.

[johnthagen]

Calling it Rust 2019 might also help relieve some of the deadline pressure that seems to be building that everything must be resolved and tested in the next couple of months. I’ve liked that up until this point, the rolling release method has allowed us Rust to avoid these sorts of deadlines until a feature is well discussed, tested, and fully baked.

For example, I was going to try out testing the new module system, but then read and was a little shocked by this in the transition guide:

Note: an alternative syntax is also under consideration: writing ::some::Local rather than crate::some::Local. If you have thoughts about this alternative, please leave a comment on the tracking issue or start a thread on the edition feedback category.

It seemed pretty big to me that the design hadn’t been resolved yet (which is totally fine if it’s given time to properly be resolved).

I just get the feeling that Rust 2018/2019 could benefit from a little more time. I’d hate for a couple months of pressure to negatively affect Rust for the next 3+ years because something got rushed.

[rpjohnst]

I believe the guide is just out of date in that. AIUI, that question has been resolved in favor of crate::, though there is the related question of relative paths: Relative paths in Rust 2018

[flavius]

I agree. In 2019, marketing Rust should be pushed more.

Compare the wordings:

Rust 2018 is hot now in 2019, try it!

vs.

Rust 2019 is hot now in 2019, try it!

Just give it one more release, put in one more feature or prepare more crates for the migration to rust 2019.

Why rush? Programmers love it, they’ll wait.

[newpavlov]

I agree about 2019. I’ve even argued for a more conservative approach and as someone pointed on reddit Rust 2020 may be the catchiest name compared to “dull” 2018/2019 and will provide enough development and testing time for new important features (futures, const generics, use and pub/crate changes, etc.), which will make edition release significantly more noticeable.

[withoutboats]

Several of these comments are conflating renaming the edition with changing the release schedule. I think there’s an argument to be made for naming it 2019, but I don’t think we’re going to change the release schedule at this point.

[aturon]

The Core Team discussed this briefly yesterday; we had already discussed this issue at length earlier in the year. Regardless of the tradeoffs, the decision was already made and the name has been publicly announced (and entrenched at this point), so this is not something we plan to revisit.

[steveklabnik]

Please note that the preview 2 has slipped a bit, though hopefully not too much! I’ll update when we ship.

[taralx]

I’m a little sad that 1.30 beta and 1.30 stable are deliberately different. I would have liked 1.30 beta to come out, with 1.29.1 or whatever in place of where you have 1.30 stable. But it’s a minor nitpick.

[steveklabnik]

I hear you. I pushed back on it too at first, but it’s realistically the best option at the moment.

[brokenthorn]

I think the opposite. Rust is not a car. You don’t facelift the old and outdated at the end of the year, naming it year++ just so it still sells one last time, before you scrape that manufacturing line to make room for next year’s newer models. Rust is a programming language that needs to evolve, but not that fast that you can’t keep up with it.Yet, you can’t put a pace on evolution. So that’s why you need to stabilise a feature set by the end of the year, so you know when you’re using it, what feature set you have access to. The feature set that made it into Rust by the end of 2018, 2019, 2020, and so forth. That way the compiler can also continue to evolve supporting several editions if need be, and bug fixes and even some new features could be more easily backported, if they’re not breaking changes.

[steveklabnik]

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