Package: release.debian.org Severity: wishlist X-Debbugs-Cc: debian-r...@lists.debian.org
Hi! I briefly asked about this a while back on IRC, and thought I had already filed this formal request/report, but it seems I failed to actually do that.. Some background information: The Rust toolchain (rustc, cargo, and some related helper tools) has a release cadence of 6 weeks. Each stable release is preceded by a Beta release (6 weeks before the corresponding stable release), after that is branched off only regression and security fixes make the cut to be included in the final stable release for that version. For example, for the current beta (1.82.0) the delta since it has been branched off on September 6th is (excluding testsuite changes to adapt to those code changes): compiler/rustc_hir_typeck/src/callee.rs | 21 ++----- compiler/rustc_hir_typeck/src/expr.rs | 25 +++++--- compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs | 39 +------------ compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs | 67 ++++++++++++++++------ compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp | 10 +--- compiler/rustc_mir_build/src/check_unsafety.rs | 14 +++++ compiler/rustc_pattern_analysis/src/usefulness.rs | 6 +- .../error_reporting/traits/fulfillment_errors.rs | 1 + library/core/src/iter/sources/repeat_n.rs | 60 ++++++++++++++----- library/core/tests/iter/sources.rs | 24 ++++++++ library/windows_targets/src/lib.rs | 1 + src/bootstrap/src/core/build_steps/doc.rs | 20 ++++--- src/llvm-project | 2 +- 13 files changed, 175 insertions(+), 115 deletions(-) or, in commit form: 1ddfc902b8595057888320176bb2d2561d9dd8fa bootstrap: Set the dylib path when building books with rustdoc 3cb89a05adcd26618a2705170279637dcf1db3a7 Don't call extern_crate when local crate name is the same as a dependency and we have a trait error 824971f5ba6f5fed99a107ea61cec479aaa541a9 Inline expected_inputs_for_expected_output into check_argument_types/check_expr_struct_fields 91b117bdc74e29c0f046c4eff623d8ed89414ac9 Use equality when relating formal and expected type in arg checking 4bf632f51e33071b397da8b858f87d9cfdb38606 Limit `run-make` tests using `-Zbuild-std` to nightly 49891df793fcb048df16dcf62072807312bf34d3 Check params for unsafety in THIR 85f29bda083958dd02bcb54b06ccd4b35523a6ff Revert "Rollup merge of #129749 - krasimirgg:llvm-20-lto, r=nikic" f004b77fdedbc977919c42fb3719b8a1298c7242 Update LLVM to 19 327ca6c e7246aefbefbcf16ae2828ecbaefcf5e8b725ae1 `RepeatN`: use MaybeUninit 03faf4f9867bb943edaf6926d1a575f046407f62 Win: Add dbghelp to the list of import libraries 7410cbf03f55788ff768a9b6f0b2f098c1ab7053 Revert warning empty patterns as unreachable 1.82.0 is slated to be released in 13 days on October 17th. 1.83.0 on November 28th 1.84.0 on January 9th 2025 In addition to nightly/beta/RC/stable releases, Rust has the orthogonal concept of "editions"[0]. These allow individual crates to opt-into using features of a newer compiler version that require breaking changes on the compiler side (like new keywords, imported by default parts of libstd, ..) without breaking the promise of "existing code continues to work with new compiler versions", and without breaking interoperability between crates using edition X and other crates using edition Y. So far, there have been three such editions - 2015, 2018 and 2021. New editions are usually adopted fairly quickly by developers (compared to other ecosystems, e.g. this is not like a new C++ standard or major python version). The upcoming 2024 edition is slated to be released as part of Rust 1.85 (planned release stable date: 2025-02-20, beta branching point 6 weeks before that, so early January). Upstream contacted the Debian Rust team to ask about Trixie, and whether it is feasible to include that version[1]. I agree with them that it would be very nice to do so, since the non-buildd use case for the toolchain packages for local Rust development would be greatly reduced without support for the 2024 edition. Depending on how the freeze timeline looks like, I see a few options: - freeze date for toolchain/key packages is after 2025-02-20, such that a regular upload of 1.85 just works out - freeze date is before 2025-02-20, no exception, we ship with 1.83 or 1.84 - freeze date is before 2025-02-20, exception to update to 1.85 after the freeze is in effect - freeze date is before 2025-02-20, but after 1.85 beta release, we upload 1.85 beta before the freeze, and then file an unblock for 1.85 beta to 1.85 stable with very small diff (see above) The first or last option would of course be the most preferred solutions from our PoV, hence this mail: - is there a tentative freeze timeline already discussed somewhere? - would it be possible to get such a beta-to-stable unblock pre-approved if it looks like the freeze will happen before 2025-02-20? we definitely don't want to be stuck on a beta release for Trixie.. Thanks for your consideration, Fabian 0: https://doc.rust-lang.org/edition-guide/editions/index.html 1: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-July/044870.html
