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

From: Phillip Wood <[email-masked]>
Date: Fri, 19 Sep 2025 14:59:58 +0100

Hi Patrick

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?

> +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 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.

Phillip

>   === Removals
>   
>   * Support for grafting commits has long been superseded by git-replace(1).
>