Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt <ps@pks.im>]

On Fri, Sep 19, 2025 at 02:59:58PM +0100, Phillip Wood wrote:
> On 15/09/2025 12:22, Patrick Steinhardt wrote:
> > Over the last couple of years the appetite for bringing Rust into the
> > codebase has grown significantly across the developer base. Introducing
> > Rust is a major change though and has ramifications for the whole
> > ecosystem:
> > 
> >    - Some platforms have a Rust toolchain available, but have not yet
> >      integrated it into their build infrastructure.
> > 
> >    - Some platforms don't have any support for Rust at all.
> > 
> >    - Some platforms may have to figure out how to fit Rust into their
> >      bootstrapping sequence.
> > 
> > Due to this, and given that Git is a critical piece of infrastructure
> > for the whole industry, we cannot just introduce such a heavyweight
> > dependency without doing our due diligence.
> 
> I'm not sure what you mean by "doing our due diligence" here. We already
> know that requiring a rust compiler will make it impossible to build git on
> some currently supported platforms. Isn't the purpose of this patch to give
> them notice so they have some time to come up with a plan for either (a)
> accelerating rust support on their platform, or (b) for how maintain the LTS
> branch after the we stop supporting it?

Yeah, I consider having an announcement of our intent out there as being
that "due diligence". The scope of breakage may be much bigger than we
currently anticipate, and if we eventually see that a significant
portion of the ecosystem would break I think we should take a step back
and reevaluate.

> > +1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and
> > +   disabled in our Makefile so that the project can sort out the initial
> > +   infrastructure.
> > +2. In Git 2.53, both build systems will default-enable support for Rust.
> > +   Consequently, builds will break by default if Rust is not available on the
> > +   build host. The use of Rust can still be explicitly disabled via build
> > +   flags.
> > +3. In Git 3.0, the build options will be removed and support for Rust is
> > +   mandatory.
> > +--
> > ++
> > +You can explicitly ask both Meson and our Makefile-based system to enable Rust
> > +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`,
> > +respectively.
> 
> This is helpful but ideally before Git 2.53 we'd make the Makefile and meson
> print that information if they fail due to a missing rust compiler.

The intent here is to allow us a bit of time to iterate on the build
infra before making either of the build systems error out. Ezekiel has a
bunch of follow-ups that we'll want to land to also unblock support on
Windows and to implement things we don't yet have, like Rust-accessible
C bindings.

Is there any particular reason why you want to accelerate this timeline
and make the build systems error out right from the start?

> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release. This long-term release will receive important bug fixes for at
> > +least four release cycles and security fixes for six release cycles. The Git
> > +project will hand over maintainership of the long-term release to distributors
> > +in case they need to extend the life of that long-term release even further. In
> > +that case, the backporting process will be handled by these distributors, but
> > +the backported patches will be reviewed on the mailing list and pulled in by the
> > +Git maintainer.
> 
> Didn't Junio have some qualms about the last part of this paragraph? I
> thought he suggested that once we hand over maintaining the LTS release the
> people responsible for it could use the security list to coordinate their
> work and would be responsible for pushing fixes the the LTS branch
> themselves.
> 
> Thanks for working on this, it will be good to have a formal plan in our
> Documentation that we can refer to.

Yeah, I addressed that feedback in [1]. Junio didn't reply to that part
yet, and I didn't have any idea for how to improve that part. I'm happy
to do so though if this still feels problematic to anyone.

Patrick

[1]: <aMfwGHL7dh8dk2cQ@pks.im>