On 2025-07-17 at 20:32:24, Ezekiel Newren via GitGitGadget wrote: > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > index 7dbf9f7f123c..8aac18a6ba45 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -4,6 +4,7 @@ on: [push, pull_request] > > env: > DEVELOPER: 1 > + RUST_VERSION: 1.87.0 Our discussed plan is to support the version in Debian stable, plus a year. So we'd be supporting 1.63.0 for a year after trixie's release. The reason for that is that people build backports and security updates for Git for stable releases of distros and they will use the distro toolchain for doing so. Forcing distros to constantly build with the latest toolchain is pretty hostile, especially since the lifespan of Rust release is six weeks. If the Rust project provides LTS releases in the future, then we can consider adopting those. > +if [ "$rust_target" = "release" ]; then > + rust_args="--release" > + export RUSTFLAGS='-Aunused_imports -Adead_code' > +elif [ "$rust_target" = "debug" ]; then > + rust_args="" > + export RUSTFLAGS='-Aunused_imports -Adead_code -C debuginfo=2 -C opt-level=1 -C force-frame-pointers=yes' Can you say a little about why these options are needed and the defaults are inadequate? For instance, I build with the default options both in my personal projects and at work and don't see a problem. I don't know if you plan to do this in a future series, but we'd also want cargo's tests to be run as part of CI and we'd want a lint job that ran clippy with both 1.63.0 and the latest stable version of Rust to make sure things were tidy. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
