Re: What will come after Git 2.56?

[Patrick Steinhardt <ps@pks.im>]

On Sun, Sep 06, 2026 at 06:14:40PM +0000, brian m. carlson wrote:
> On 2026-09-06 at 07:03:20, Junio C Hamano wrote:
> > 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.

Well, same as there's room after Git 2.9 we also still have room after
Git 2.99. No reason we cannot have Git 2.100. :)

> >  (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);

Yeah, GitHub is the biggest question mark for me, and I wouldn't want to
pull the trigger before it supports it. So I'm looking forward to your
update!

> * any updates on libgit2 and its support for SHA-256 and reftable; and

I have upstreamed support for reftables into libgit2 now [1]. And SHA256
support was default-enabled in [2] now, which was merged roughly a month
ago. So once the next release is out I think both of these blockers
should be removed.

Patrick

[1]: https://github.com/libgit2/libgit2/pull/7117
[2]: https://github.com/libgit2/libgit2/pull/7261