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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA