Git fork

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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

authored by

Patrick Steinhardt and committed by
Junio C Hamano
8f5daaff 8832e728

+45
+45
Documentation/BreakingChanges.adoc
··· 165 165 "reftable" format. Most importantly, alternative implementations of Git like 166 166 JGit, libgit2 and Gitoxide need to support it. 167 167 168 + * Git will require Rust as a mandatory part of the build process. While Git 169 + already started to adopt Rust in Git 2.49, all parts written in Rust are 170 + optional for the time being. This includes: 171 + + 172 + ** The Rust wrapper around libgit.a that is part of "contrib/" and which has 173 + been introduced in Git 2.49. 174 + ** Subsystems that have an alternative implementation in Rust to test 175 + interoperability between our C and Rust codebase. 176 + ** Newly written features that are not mission critical for a fully functional 177 + Git client. 178 + + 179 + These changes are meant as test balloons to allow distributors of Git to prepare 180 + for Rust becoming a mandatory part of the build process. There will be multiple 181 + milestones for the introduction of Rust: 182 + + 183 + -- 184 + 1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and 185 + disabled in our Makefile so that the project can sort out the initial 186 + infrastructure. 187 + 2. In Git 2.53, both build systems will default-enable support for Rust. 188 + Consequently, builds will break by default if Rust is not available on the 189 + build host. The use of Rust can still be explicitly disabled via build 190 + flags. 191 + 3. In Git 3.0, the build options will be removed and support for Rust is 192 + mandatory. 193 + -- 194 + + 195 + You can explicitly ask both Meson and our Makefile-based system to enable Rust 196 + by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`, 197 + respectively. 198 + + 199 + The Git project will declare the last version before Git 3.0 to be a long-term 200 + support release. This long-term release will receive important bug fixes for at 201 + least four release cycles and security fixes for six release cycles. The Git 202 + project will hand over maintainership of the long-term release to distributors 203 + in case they need to extend the life of that long-term release even further. 204 + Details of how this long-term release will be handed over to the community will 205 + be discussed once the Git project decides to stop officially supporting it. 206 + + 207 + We will evaluate the impact on downstream distributions before making Rust 208 + mandatory in Git 3.0. If we see that the impact on downstream distributions 209 + would be significant, we may decide to defer this change to a subsequent minor 210 + release. This evaluation will also take into account our own experience with 211 + how painful it is to keep Rust an optional component. 212 + 168 213 === Removals 169 214 170 215 * Support for grafting commits has long been superseded by git-replace(1).