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.