Re: What will come after Git 2.56?

>
> 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.
> >
> >  (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.