Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Tue, 22 Sep 2026, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Mon, 21 Sep 2026, Junio C Hamano wrote:
> >
> >> Git 2.56-rc1 has been tagged.  We may merge last-minute fixes before
> >> the final Git 2.56 release, but otherwise I do not expect any new
> >> feature topics to be ready before the final, so most of the
> >> in-flight topics will stay cooking in 'next' until then.  As
> >> discussed at the Git Contributors' Summit, the version after the
> >> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
> >> year.
> >
> > Would you say that the following is an accurate characterization of the
> > timeline, so that people who need to plan dependent projects can rely on
> > it?
> 
> My outline was deliberately limited up to end of this year as I am
> hesitant to say beyond that point before the meeting notes are made
> public.  I am not sure who will be releasing it to the public and
> when, though with the open nature of this community I believe it
> will happen soon.  I do not recall anything controversial in the 3.0
> section of the meeting notes.

Fair enough: I did ask you to confirm my summit summary. Let me separate
that from what I need for planning: a proposal from you as release
maintainer can be discussed on the list on its own merits, without waiting
for publication of the meeting record or claiming summit consensus.

Could you use the next What's cooking to outline your working release
plan: whether paired 2.99.1/3.0 releases in March or April 2027 would be
your proposed target, what conditions could move it, and when we should
review that target?

If you cannot yet choose a target, could that update identify what needs
resolving and when you expect to revisit the choice?

Your assessment would give dependent projects a common baseline to
coordinate around. A provisional planning assumption would be useful; it
need not be a guarantee.

Thanks,
Johannes