Re: What will come after Git 2.56?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 6, 2026, 18:14 UTC
Message-ID: <ap2tjx0z7kiFjDM9@fruit.crustytoothpaste.net>
In-Reply-To: <xmqqmrtu50av.fsf@gitster.g>

On 2026-09-06 at 07:03:20, Junio C Hamano wrote:

Show 25 quoted lines

> http://tinyurl.com/gitcal tells us that the current development
> cycle for Git 2.56 will conclude around the end of this month.  As
> our typical development cycle lasts between 8 and 12 weeks, we will
> have exactly one more cycle after that before the end of the year.
> 
> Now, the question is what that release should be called.  A few
> thoughts.
> 
>  (1) Git 3.0: it is tempting to conclude the year with a big
>      version bump.  Splash!
> 
>  (2) Git 2.99: by leaving no more room until 3.0, we will
>      conclude the year with a version that is still in the 2.X
>      series, but will hopefully force us to seriously prepare for
>      a big version bump with the first release of the year 2027.
> 
>  (3) Git 2.98 (or 2.97): we admit that we are not ready for even
>      (2) and chicken out, leaving us breathing room for a few
>      more preparatory releases before the big one.
> 
>  (4) Git 2.57: doing business as usual.
> 
> Needless to say, this is not a popularity contest, nor is it even a
> democracy.  Regardless, we should review what we have in the
> 'BreakingChanges' document and ask ourselves how ready we are.

There are a few remaining things I think we should consider in regards to this:

* forge support for SHA-256 on the remaining major forges (I have an
  update to provide about this at Git Merge);
* any updates on libgit2 and its support for SHA-256 and reftable; and
* the lowercase-only object IDs series, which I will be sending out a
  re-roll for today or tomorrow and which is a breaking change that we
  may want to soak for a release or two.

I think anyone else who is not already extremely far along on SHA-256 (and reftable, for software working with local repositories) is likely not worth considering. JGit and Gitoxide were both informed that SHA-256 was coming in Git 3.0 at least a year ago, for instance. (I know because I did the informing.)

Similarly, I am not aware of anyone who is seriously undertaking Rust support for platforms that do not already support it, so I don't think that should be a blocker, either.

So my gut reaction would be that maybe 3 is the best choice. 2.97 might be nice, or we could be more careful and go with 2.95 and then skip ahead to 3.0 whenever we're ready.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA