Edition Brainstorming

# Edition Brainstorming ## Ed's opening comments: 6 week release cycle good: not so stressful editions bad: - very stressful no point working on a feature now because it will take 3 years to arrive. Then right before the edition we rush - some people aren't aware of edition deadlines (rustdoc?) ## Editions: the good points - *Big splashy announcement*, people who are less tied in get a big opportunity to hear about new features - This benefits from it being a longer cycle (e.g. 3 years) - Oppourtunity to sync up less connected elements in the comunity. - If it were too frequent then the marketing part of it would be harder - Being able to do breaking changes / cleanup, without losing stability guarantees - This seems like a rare combination; projects with stability don't usually get to clean up past issues; projects that fix past issues don't usually have as much of a stability guarantee. - C++ committee would kill for this - Editions are per-crate, don't need to fragment the ecosystem because your dependencies can have a different edition than you - One big feature flag makes it nicer in the compiler, having lots of small conditionals everywhere would be more complicated - People only have to addpt every 3 years, so they can do it and then know they have 3 years of stability. - 3-year release cycle is consistent (and 6-week release cycle is very consistent) - Rally-point for the project, people think big about things that need an edition - Forcing function to push forward discussoions and work to get the feature done - e.g. the RFC that was deadlocked where the deadline for the Edition helped to uncover it so it could be resolved and moving forward again - Can do better language design if you know an edition is coming. - You know you can always get another keywork in the next edition, can use `k#keyword` for now - Means you can avoid do `do yeet` or reusing a keyword like `as` for a purpose it wasn't designed for. - Makes testing nicer. You don't have to test the power set of every enabled feature, you can only take them linearly - Very important, also for some kind of design of future edition-like systems. - You choose when to adopt an Edition for what works for you - If you are busy shipping a product or similar, you don't have to jump on the edition right away - Software that's "done" can stay with an edition forever, it doesn't *have* to be updated or die ## Editions: the bad points - Need to keep around both old and new behavious in compiler - Editions do not allow you to remove code from the Rust codebase and clean up - Compiler/tools can only ever get more complicated. - Hard to deal with deadlines - Temptation to treat the deadline as soft *because* it's a 3-year train and missing it is painful - Every 3 years, means threat of missing the train leads to rush to get everything into the edition at the end. - No documentation about mistakes from the previous edition. Knowledge is lost as maintainers churn over. - Continual churn of contributors mean many contributers were'n arround for the last eddition. - Similar to a student organization, where people graduate and institutional knowledge is lost - Edition Lore never written down, only people who were there in 2018 know what it was like. - No pressure at the start of an edition cycle, benefits won't come for 3 years - Companies and contributors don't necessarily plan on 3-year cycles, hard to justify working on it now - Large cause of burnout for people - Very stressful, especially at the end - Designed to solve lang problems, works well for Cargo, being adopted by style/rustfmt, but can't easily be used by the library teams or other teams - No real story written down for the rest of the project. - - Makes stakes higher, if people fail to get stuff into the edition, there's no real option for recovery. - If you fail, you feel like its over and you might not be able to go on. - Need someone to coordinate edition, but it's made of burnout, very high pressure. Temptation/draw of being a "hero". - Edition lead pulled from other projects. - Can't fund a full time "edition person", becasue work ramps up and down. - Not obvious how much work it is from the outside, people don't see how much work is required - Only noticed when it's done badly. ## Freeform Discussion We could ship an empty edition is a week. We could probably make this faster if we did it often. Shipping a feature in the edition is a lot like shipping another feature, it takes organization and it might be short or long, but the fact that it ties into an edition is not itself making it take *much* more overhead. We don't have a process for shipping edition things in the first year of the 3-year cycle. So if something slips, even if you're willing to wait 3 years, you can't just go ahead and add it to the *next* edition right away. We can't just ship an edition every single version, we'd burn out our users. So you need to balance the time between editions. There's a bunch of work needed for the edition itself that isn't tied to one feature, like documenting everything in the edition, writing the edition guide, splashy announcements on the website, etc. Release notes are an example of this problem. People who write the PRs don't write the relnotes (even a draft), don't explain why something's important. All that work is on whoever writes the release notes. And they might miss something because they don't know why it's important or how to explain it. We have relnotes for regular releases, we don't have them for editions. Editions have two phases: too early to talk about the edition and too late to get something into the edition. Because all the edition work is compressed into the last part of the edition cycle, the attempts to separate edition RFC writing/accepting from implementation feels challenging and there isn't enough time for it. So, RFC writing/accepting overruns any deadline we set for it. Edition guidance appears in multiple places: the edition guide, and the Cargo documentation, and maybe other places? User testing is hard? Any person we hire has to have a non-traditional PM role, more of a facilitator role. A big problem with faster Editions is retraining what is idiomatic Rust. Maybe we decouple that from faster-paced Editions. ## Potential Solutions (Just cataloguing right now, not evaluating.) - Try to figure out the best cadence for editions - Might be somewhat less work on a more frequent cadence, but there's some fixed work for each edition - Have an "edition next", maybe tie it to `rust-version`? - Make it possible to start using edition features as soon as they're stable, before the edition itself ships. - Take inspiration from the Python community, `from __future__ import feature_name` - Can use feature flags to enable "stabilized edition features" without having the whole edition stabilized yet. - An edition is a "bundle" of features - Should talk about whether you're allowed to enable arbitrary combinations of features. - Can you be on 2024, not enable 2027, but enable specific features from both the 2027 and 2030 editions? - Make every release an edition. - Rust Foundation helps us hire a full-time edition manager - This should probably be paired with a cadence change. - Alternatively, they can tell us what sort of cadence makes sense. - Have a single team responsible for **all editions** (as opposed to a 2018 team, 2021 team, ...) - Have a "design and roadmap" team, that handles both edition and non-edition changes. - This means you don't need frequent cadence for a full-time person. - This means there will definitely be enough work for an organizer/edition person to do - Rust needs like 50 "traditional PM"'s. You need to empower them to not do all the things. - Documenting the edition contents is good for users, and maintainers, also to prioritize what to work on. Everyone should know what is expected from them. # Consensus positions * Edition should be something we are always working on, not wait until last minute and `panic!` * We ought to be talking to users -- * How frequent is palatable and why? We can't answer this question * Leadership council is the right group to approve this * Might tie in with LTS and modified release cycles (predictable release date)