On Sun, Jul 28, 2024, at 1:49 AM, Travis Cross wrote: > Greetings. We understand there to be ongoing discussions about the > selection of the Rust release to include in Debian Trixie, and > relatedly, discussions about the freeze schedule for Trixie. We've > heard there may be tentative plans to use Rust 1.83 (which we will > release on 2024-11-28) and to freeze in mid-January. We heard that > you were hoping to freeze the Rust toolchain sooner rather than later > in the upcoming window, due to it being a dependency of many other > things.
Hi (and thanks for reaching out)! Just for the record, there haven't yet been any real discussions, but rather a rough estimation what seems realistic based on past freeze periods. For past releases the freeze happened around January[0] for toolchain and other key packages[1] (these are frozen first, since any bigger changes there obviously have a lot of knock-on effects in the rest of the packages/archive). The exact freeze times and policy[2] are not decided by individual maintainers or packaging teams, but by the release team (CC-ed accordingly). None if has yet been finalized/announced for the upcoming Trixie release, but I expect that rustc/cargo will be part of the set of key packages again (compared to the Bookworm release, their usage is even more widespread after all! :)), that those will be frozen first again, and that the rough timeline give or take a few weeks will be similar to that of Bookworm. The historic trend goes towards shorter freezes. > Some time ago, within the Rust project, we finalized our plans and > scheduling for the Rust 2024 edition.[1] We're planning to release a > new edition, Rust 2024, with Rust 1.85 (which we will release on > 2025-02-20).[2] > > We would advise that, if at all possible, the Debian project consider > including Rust 1.85, and therefore Rust 2024, in Debian Trixie. Given > the expected two-year life of Trixie as the latest release of Debian > stable, and the many users of Debian stable who use Debian-shipped > toolchains to build projects such as the Linux kernel[3], it'd be > helpful if those users were able to make use of the Rust 2024 edition. That does indeed sound sensible from a "how useful are those toolchain packages for the duration of Trixie being stable" point of view, assuming lots of crates will switch to the new edition quickly and thus become unusable with any rustc < 1.85. > We'd be happy to help facilitate that, if we can. > > Rust releases happen on a strictly time-based train model, where, for > each release, we freeze and release a beta six weeks ahead of time. > We make backports only infrequently onto the beta branch (which are > always minimal and conservative) between the beta and the final > release. Often, the beta is simply "promoted" to the stable release > with no changes. The beta for Rust 1.85 will be released on > 2025-01-09. Depending on the freeze schedule, perhaps using the beta > and seeking a freeze exception for the final release could be an > option, so that the actual code delta for any potential freeze > exception is likely to be near zero. That might be easier than > justifying the full delta from 1.83 or 1.84 to 1.85. We would also be > happy to provide any supporting documentation for a freeze exception, > if needed, based on Rust's unusually strong history of stability > guarantees. We do actually have support for pulling in beta releases when upgrading the toolchain package(s), although I haven't used it yet (since I've been mostly busy catching up to current stable releases one by one). I'm currently packaging 1.80, but afterwards I could give it a try and fix up any bit rot that might have crept in over the years since it was last used, and package the 1.81 beta in August. AFAIR, both beta to RC to release, as well as the occasional point releases/hotfix releases afterwards, have been fairly limited in scope for as long as I have been following these developments. Both kinds of delta should fit within the usual "targeted fixes only" approach Debian takes for packages during the freeze or for stable itself in point releases in my opinion. > We can also help with any potential issues that arise during that > window (e.g. if testing within Debian turns up an issue with 1.84 or > 1.85 that impacts Debian packages), and prioritize beta backports or > reverts accordingly. That's good to know - aligning with upstream projects w.r.t. which version to package is always good, and having buy-in from both sides obviously is best ;) > We're hoping this schedule information and offer of assistance will > make it easier to make plans for the version of Rust in Trixie. > Thanks again for your work to bring Rust to Debian users and > developers. FWIW, from the Rust team/rustc maintainer side, I'd be happy to package up 1.85 beta in January if that aligns with the freeze, and then pull in the final release a few weeks later using the regular unblocking process we have during the freeze period. Obviously, under the condition that the release team has no objections :) If that doesn't work out/is not acked, there is always the option of providing a more recent version via Debian backports once Trixie has been released. I have been pondering doing that in any case for quite a while already. @Release team: should we move such a discussion to a bug somewhere, or is a regular thread fine for now as well? @Rust people: the annual Debian conference debconf is currently going on, and summer holiday season in general is upon us, so it might be a bit before this discussion concludes (or even continues ;)). But we still have a few months anyway! 0: https://lists.debian.org/debian-devel/2022/03/msg00251.html 1: https://release.debian.org/testing/essential-and-build-essential.txt 2: https://release.debian.org/testing/freeze_policy.html > [1] We know the Debian Rust team will already be familiar with > editions, but as background for others: > > Periodically, and historically every three years, the Rust project > releases a new *edition*. Editions are a way in which we allow users, > on a library-by-library basis (we call them "crates") to opt-in to > certain new behaviors. New Rust compilers continue to support old > editions (forever) to avoid breaking any existing code, and one build > of a Rust project can incorporate crates that use different editions, > so an entire project need not migrate all at once. We encourage > adoption of new editions, and in practice, observationally, these tend > to be rapidly and widely adopted by our ecosystem. > > [2] This is a time-based release date, and we don't expect to bump the > edition to a later release. While we are a project of volunteers, > like Debian, and so things could always change, we have at this moment > a lot of confidence and substantive reasons to believe that we will > hold that date. > > [3] Linux kernel development is affected by this decision because of > the Rust for Linux (RFL) project. Some kernel maintainers have stated > that they will only get involved with Rust kernel development when > they can compile the mainline kernel with the toolchain provided in > their distributions. Therefore, the kernel is starting to support a > range of Rust toolchain versions, with Rust 1.78 as the initial > minimum supported version. In evaluating the next minimum version of > Rust that we'll support, the kernel is taking into account the version > of Rust that will be included in the upcoming release of Debian > stable. If that version supports Rust 2024, then it is likely the > kernel will migrate to it early, since it would provide kernel > developers with the latest improvements to the language.
