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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 23, 2025, 17:29 UTC
Message-ID: <xmqqecrxoz5h.fsf@gitster.g>
In-Reply-To: <d323c453-a800-413d-82d6-b0db0a4b76c0@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 10 quoted lines

>> +We will evaluate the impact on downstream distributions before making Rust
>> +mandatory in Git 3.0. If we see that the impact on downstream distributions
>> +would be significant, we may decide to defer this breaking change to a
>> +subsequent minor release. This evaluation will also take into account our own
>> +learnings with how painful it is to keep Rust an optional component.
>
> I think this last paragraph is a welcome addition as it makes it clear
> we're not going to blindly pursue rust if it causes widespread
> problems. Personally I'd say "experience" rather than "learnings" but
> that's probably me being a grumpy pedant.

If this transition turns out to be way too disruptive even for the 3.0 that promises big changes anyway, can "this breaking change" realistically be "deferred" to a subsequent "minor" release?

The only way I can think of that is permissible in a minor release would be to pear it down so much that it no longer is disruptive, but that would be very different from "this breaking change" anymore.

Or is this talking about waiting until the downstream distribions either die out without adding Rust support or start supporting Rust? That, except for the risk of having to wait forever, might work, but then to surviving distros, it would no longer be a "breaking" change even if we ship the same change as "this breaking change", right?

I don't know. To me, the last sentence sounds like reserving the right to later say "we learned that trying to support opt-in Rust component that we have to (partially) replicate in C is so painful, so we won't keep Rust an optional component".