On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > > It looks like this version does include the necessary Makefile changes which > > is great. I do think though, that for the test balloon to be valuable, we > > need make building with rust the default with an error message that tells > > people how to build without rust if that fails. Otherwise it is easy for > > people building on platforms without rust support to miss that we're going > > to be making it mandatory soon. > > I have a plan layed out in the BreakingChanges document that mentions > how I'm proposing to do the transition: > > 1. We introduce it with auto-detection for Meson and default-disabled > for our Makefile in Git 2.52. > > 2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled > in Git 2.53. > > 3. We always enable Rust by default in Git 2.54. I don't see how steps 1 & 2 help at all. We now know we want to make Rust mandatory eventually, and should provide distributors and platforms as much notice as possible so they are aware. But what you've proposed is another libgit-rs or libgit-sys -- an optional component that no one will know about unless they go looking for it. I don't see how those two steps provide any incremental help to anybody over what libgit-rs and libgit-sys have done. From my point of view, Rust should be enabled by default in Git 2.52, with a simple knob provided to let distributors/platforms/users turn it off and build without it. > 4. We unconditionally enable Rust in Git 3.0. > > This is basically gradually tightening the screws, which both gives us > time to build the infra and gives downstream time to become aware of the > change and adapt. > > I think making it mandatory in Git 3.0 makes sense because I also > propose to make the last version without mandatory Rust be an LTS > version. And if we connect that with it being the last version before > 3.0 I think that's an additional benefit, as there will be other > breaking changes in 3.0. > > In the end it kind of hinges on when we think we want to release Git > 3.0. If we can agree on the above plan, we could also think about making > Git 2.55 become 3.0 instead. That'd be in a bit less than a year from > now, which I think is a good timeframe for that breaking release. I > personally don't see a reason to push it out into the future for way > longer than that, and it would be good anyway if we built some consensus > around its release date. I see your plan, but I agree with Phillip that I don't see why it makes sense to lump the Rust transition with the 3.0 transition. Setting that aside for a moment, the idea of Git 2.55 becoming 3.0 seems like a good idea to me, assuming that doesn't rush brian on the sha1/sha256 interop (since I think that's probably the paramount feature of 3.0).
