2024 Edition

text/3501-edition-2024.md

@@ -0,0 +1,88 @@
+- Feature Name: `edition_2024`
+- Start Date: 2023-09-25
+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)
+
+# Summary
+[summary]: #summary
+
+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.
+
+[RFC 3085]: https://rust-lang.github.io/rfcs/3085-edition-2021.html
+[project group]: https://rust-lang.github.io/rfcs/2856-project-groups.html
+
+# Motivation
+[motivation]: #motivation
+
+So far, editions have been delivered on a three-year cadence, with the 2015, 2018, and 2021 editions.
+Many within the Rust project have been expecting this trend to continue.
+The three-year cadence seems to hit a reasonable balance of not too often, but still providing opportunities for potentially breaking changes to be introduced.
+
+By establishing a three-year cadence, this removes the ambiguity of what the expectations are around scheduling and releases of new editions.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+## 2024 Edition
+
+The Rust Project intends to create a 2024 Edition.
+Currently, no specific changes are being announced in this RFC for this edition.
+Team members will be responsible for identifying changes they want to make and coordinate with the Edition project group.
+
+## Edition project group
+
+The Leadership Council will be responsible for forming a project group for coordinating each edition release.
+The Edition project group is responsible for:
+
+* Ensuring that the process follows the accepted policy, such as [RFC 3085] and this RFC.
+* Establishing a schedule for the edition ([example][example-schedule]).
+* Building consensus within the Edition project group on which changes will be accepted for the edition in coordination with the affected teams.
+* Coordinating with teams to ensure that edition changes are on track for release.
+* Making recommendations to the Leadership Council if the edition should be released in another year.
+* Making public announcements, such as blog posts to solicit support in creating the edition, calls for testing if needed, and informing users about the changes planned.
+* Ensuring that the requisite changes in tooling for changes are available in the nightly release, such as adding unstable edition flags.
+* Informing the relevant people to be aware of any issues related to the edition and tracking for getting those issues resolved.
+* Ensuring that sufficient testing, such as crater runs, gets done in time to be evaluated and for issues to be resolved.
+* Ensuring that automated migrations are in place, and should cover the majority of users.
+* Ensuring documentation, such as the [Edition Guide], is updated, ideally in time for users to begin testing before the release.
+* Ensuring that the stabilization process happens on schedule.
+* Monitoring adoption of the edition after the stabilization, and identifying issues that may need to be addressed after the release.
+* Continue to evaluate if the three year cadence makes sense, and potentially make recommendations to the Leadership Council for changes to the edition process.
+
+The Edition project group and the Leadership Council may approve minor changes to the process outlined above without public comment.
+
+Major changes to the edition process, such as discarding the three-year model, must be made via the RFC process.
+
+[Edition Guide]: https://doc.rust-lang.org/edition-guide/index.html
+[example-schedule]: https://hackmd.io/@m-ou-se/Byh6x1thv
+
+## Edition cadence
+
+Editions are intended to be released on a three-year cadence.
+
+The Leadership Council is responsible for deciding what to do if an edition does not have sufficient changes ready to justify the edition.
+Some possible options include skipping the edition completely (and keeping the regular 3 year cadence), delaying to a subsequent year, or stabilizing the edition without any specific changes.
+It is not expected for this to happen in 2024, or even 2027, and thus trying to predict the circumstances in 9+ years is out of scope for this RFC.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+## Cadence may artificially delay changes
+
+Some changes may be ready within the first or second year after an edition is released.
+Or, a change may just barely miss an edition window if last-minute issues arise.
+Forcing those changes to wait one to three more years before they can be used can be a frustrating experience.
+
+A more frequent cadence may allow those changes to be available in a more timely manner, and potentially reduce the stress associated with the release process.
+It is intended for the Edition project group and the Leadership Council to continue to evaluate the cadence and to decide if a different approach is preferred in the future.
+
+## Stress around deadlines
+
+Preparing and releasing edition changes, with such a rare window for release, can be a stressful process.
+Changes often taken longer than expected, and since most people are offering their effort as a volunteer, it can be difficult to get everything ready in time.
+Additionally, there are many time-consuming manual steps in the release process, and the Edition project group has to coordinate with many different teams, which can be exhausting.
+
+It is recommended that the Edition project group establish a schedule that gives plenty of lead time, very publicly share the schedule, and to recognize the risk of excessive stress throughout the process and to try to identify strategies to mitigate it.
+The Edition project group should also be prepared and willing to discuss options with the Leadership Council of releasing in a different year if the schedule is at risk.