-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2024 Edition #3501
2024 Edition #3501
Conversation
An alternative worth evaluating: rather than considering delaying an edition by a year, we could commit to a three year cadence and just skip an edition if there are no incompatible changes to ship. |
^^ that would be my preferred solution as well. |
Yeah if an edition name ever doesn't fit the format "2015 + 3*N" then we've really messed up. It's very clear that way, absolutely no reason to mix it up. People should be able to list all the editions in their sleep. |
I am in favor of the 3-year cadence. If we slip at some point, we'll figure it out then, but my personal take is that editions should ship, and if we have to cut scope, we cut scope to make that happen. I think it's really important to make progress. I also think we should work out processes to be constantly developing the next edition as we go, we talk about this every year, but I don't think we need an RFC to make that happen. (I favor the idea of |
As for the question of what to do if we have no changes... I think we probably skip but I feel like that's a conversation we can have at the time. |
One small note on skipping editions: I think that edition numbers should still be valid for skipped editions, just fall back to the previous edition. For example, if the 2024 edition is a bust and we add nothing, it should be valid to refer to the 2024 edition, just, it should be treated as an alias for the 2021 edition and maybe throw a warning. |
How would that be any different than an empty edition? |
Some people have expressed different thoughts on how this scenario should be addressed. However, it seems like it will be a very situational event, and trying to predict exactly what we should do seems over-prescriptive. The RFC leaves the decision up to the Leadership Council who is expected to take the different circumstances and desires into consideration.
Thanks for the feedback! I made some small adjustments to the text around the "skipping an edition". It seems like it will be a very situational event, and trying to predict exactly what we should do seems over-prescriptive to me. I also don't expect it to happen in this edition, or even the next, and trying to predict the circumstances in 9+ years seems very difficult to do. I adjusted the RFC to clearly leave the decision up to the Leadership Council who is expected to take the different circumstances and desires into consideration. I hope that accommodates what people have been saying. We could force a specific option (like "release with whatever is ready, even if it is empty"), but I strongly suspect that it will be highly situational and I would like to give some flexibility to adapt to the circumstances. |
feat: Add `Edition2024` [RFC for `Edition2024`](rust-lang/rfcs#3501). While the RFC is not yet merged, this follows rustc which added the 2024 edition previously in rust-lang/rust#94461 This PR adds `Edition2024` as a possible value for `edition = "xxxx"`. I did this by following the [guide here](https://github.com/rust-lang/cargo/blob/ed0a7873107f48079a424da2920f7d434fd22fdc/src/cargo/core/features.rs#L163-L174).
I'm going to kick off FCP for the leadership council as we've had a few weeks of comments here and I think we can start collecting checkboxes. @rfcbot pr merge |
Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I think there could also be a working group for writing the new Rust book, and documenting Rust 2024 edition. Also, when is Rust 2024 Edition intended to be released? I mean, probably sometime in 2024, but in what time-frame. For Rust 2021 it was October, so would the 2024 edition also be around that time frame? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a release (new edition) every two years would be good.
The exact release date has not yet been determined, but sometime in 2024. |
Okay, thank you for the clarification. |
Apologies for the delay. If you can, please @ thejpster if you @ this account, as my notifications are a mess. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@jonathanpallant I feel bad for your email inbox. |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Huzzah! The Leadership Council has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: |
this is exciting! |
This RFC is an amendment to RFC 3085 to declare that the Rust Project intends to produce a new edition in 2024, to set up a project group to deliver the edition, and to establish a tentative cadence for future editions.
Rendered