On Mon, Jan 27, 2025, at 11:34 AM, Emilio Pozuelo Monfort wrote: > On 04/10/2024 15:04, Fabian Grünbichler wrote: >> 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.. > > Given the freeze timeline, I think a regular update should work. But given > the > importance of rust, please test it thoroughly before uploading to sid > (autopkgtest for rdeps, mass-rebuild, etc).
I agree w.r.t. timeline :) I'll prepare the 1.85 beta soon for experimental. rustc uploads trigger a metric ton of autopkgtest across the packaged Rust ecosystem precisely to catch regressions, and packages with actual executables (a small subset of all Rust packages) are usually binNMUed by Sebastian(?IIRC) if they don't happen to be uploaded shortly afterwards anyway. The fallout is usually very small though (e.g., with 1.84 we had one actually unrelated unsoundness issue, one package that required a tiny fix to follow an upstream rename that was already causing deprecation warnings for a few rustc releases, and one with test cases matching compiler output that changed slightly).
