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

> 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.
> 
> Instead, preceding commits have introduced a test balloon into our build
> infrastructure that convert one tiny subsystem to use Rust. For now,
> using Rust to build that subsystem is entirely optional -- if no Rust
> support is available, we continue to use the C implementation. This test
> balloon has the intention to give distributions time and let them ease
> into our adoption of Rust.
> 
> Having multiple implementations of the same subsystem is not sustainable
> though, and the plan is to eventually be able to use Rust freely all
> across our codebase. As such, there is the intent to make Rust become a
> mandatory part of our build process.
> 
> Add an announcement to our breaking changes that Rust will become
> mandatory in Git 3.0. A (very careful and non-binding) estimate might be
> that this major release might be released in the second half of next
> year, which should give distributors enough time to prepare for the
> change.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/BreakingChanges.adoc | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
> index f8d2eba061..0512411030 100644
> --- a/Documentation/BreakingChanges.adoc
> +++ b/Documentation/BreakingChanges.adoc
> @@ -165,6 +165,44 @@ 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 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 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.
> ++
> +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.