Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt <ps@pks.im>]

On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:
> On Fri, 5 Sep 2025, Patrick Steinhardt wrote:
> > Over the last couple of years the appetite for bringin 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 haven't yet been able to implement a Rust toolchain,
> >    even though it is possible in theory.
> > 
> >  - Some platforms don't have any support for Rust at all.
> 
> What's the difference between these two kinds of platform? It should be
> theoretically possible to build rust tooling for all of them, right?

The first platform is something where Rust just hasn't been wired up
yet. This involves for Cygwin, or the Darwin ports of Gentoo's portage
tree. Rust is available for those platforms in theory, but in practice
it's not there yet.

The second platform is where there is no Rust compiler available at all.
So for example NonStop, Intel Itanium, Alpha.

I'll try to clarify this in the next version.

> > diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> > index f8d2eba061..dbb15b6a57 100644
> > --- a/Documentation/BreakingChanges.adoc
> > +++ b/Documentation/BreakingChanges.adoc
> > @@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the
> > "reftable" format. Most importantly, alternative implementations of Git like
> > JGit, libgit2 and Gitoxide need to support it.
> > 
> > +* Git will require Rust as a mandatory part of the build process. While Git
> > +  already started to adopt Rust in the Git 2.52, all parts written in Rust are
> > +  optional for the time being. This includes:
> > ++
> > +  ** Subsystems that have an alternative implementation in Rust to test
> > +     interoperability between our C and Rust codebase.
> > +  ** Newly written features that are not mission critical for a fully functional
> > +     Git client.
> > ++
> > +These changes are meant as test balloons to allow distributors of Git to prepare
> > +for Rust becoming a mandatory part of the build process. There will be multiple
> > +milestones for the introduction of Rust:
> > ++
> > +1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and
> 
> Support for Rust will be detected by Rust? Should that say "by Meson"?

Ah, yes.

> > +   disabled in our Makefile so that the project can sort out the initial
> > +   infrastructure.
> > +2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled
> > +   with breaking changes. Breaking changes can be enabled for Meson by saying
> > +   `meson configure -Dbreaking_changes=true` and for Makefiles via `make
> > +   WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with
> > +   breaking changes, but explicitly disable Rust.
> 
> Mandatory, but not mandatory? opt-out?

True, this reads a bit awkward.

> > +3. In Git 2.54, both build systems will default-enable support for Rust so that
> > +   builds will break if Rust is not available on the build host. The use of Rust
> > +   can still be explicitly disabled via build flags.
> 
> I assume you mean that we will default to building with Rust, even when
> building without breaking changes, but I feel like the wording could be more
> explicit.
> 
> Assuming packagers read this when 2.52 is released, 2.54 would give them
> roughly 16-26 ish weeks of a heads up, assuming our typical 8-13 week
> development cycles.

Ok.

Does this revised version of the plan read better to you?

    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, support for Rust will be enabled by default in case Git is
       compiled with breaking changes. Breaking changes can be enabled for Meson by
       saying `meson configure -Dbreaking_changes=true` and for Makefile-based
       builds via `make WITH_BREAKING_CHANGES=YesPlease`. It will still be possible
       to compile with breaking changes, but explicitly disable Rust.
    3. In Git 2.54, both build systems will default-enable support for Rust even
       when breaking changes aren't enabled. 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.
    4. In Git 3.0, the build options will be removed and support for Rust is
       mandatory.

> > +4. 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.
> > ++
> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release that is maintained until alternate Rust backends like gcc-rs are
> > +able to build Git. The Git project may need to rely on distributions to help
> 
> Do we want to commit to promising support until gccrs is ready? What if
> gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> where it can build Git? It might make sense to give this LTS release a time
> limit instead, or in addidtion.

Yeah, I wasn't quite clear on that one, either. An alternative:

  - We will maintain the LTS release for 8 release cycles, which equates
    to roughly two years. It sounds like a lot, but recent security
    releases have stretched quite far into the past.

  - If there are still dependents after these two years we will hand
    over maintainership of the LTS branch to dependents. So they will be
    responsible for the backporting.

This really only is a suggestion though. I'm especially waiting for
Junio's feedback here to see whether he thinks that this is a reasonable
thing to do.

Patrick