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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> As I wrote, after the current cycle ends at the end of this month, a
> ...

It was so full of typoes and grammos because I didn't pass it thru
spell checker as usual.  Sorry about that.  Here is a replacement.



As I wrote, after the current cycle ends at the end of this month, a
10-to-12-week cycle including the end-of-year slowness would mean the
next cycle, 2.98, will end at the end of this year.  Extrapolating
from there, 2.99 will be March 2027.

The consensus in the room was that we want to use 2.99 as a signal
that something big is coming, so there needs to be some lead time
between 2.99 and 3.0 for "advertisement".  This lead time between
2.99 and 3.0 does not have to be the usual 8-to-12-week full release
cycle.

I do not think there was a firm agreement on the date for 2.99.1 and
3.0.  Potential factors mentioned in the room included that we may
want to match the LTS release schedule of major distributions.  My
preference would be to give a month after 2.99 to apply only
accumulated bugfixes and nothing else, and tag it as 2.99.1, which
means 2.99.1 would be April 2027.

The contents of 3.0 should be identical to 2.99.1 except that
breaking changes are enabled in 3.0 while they are disabled in
2.99.1.  Volunteers can run the 2.99.x series indefinitely to help
LTS distributions.

At the release engineering level, I am very tempted to keep the
WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to
keep the differences between 2.99.1 and 3.0 to an absolute minimum,
and then remove the "dead code" that is used when
WITH_BREAKING_CHANGES is not enabled from the 3.x series at our
leisure.

So the above is what I have in mind, shaped mostly around the
consensus at the Contributors' Summit (or at least how I understand
what the consensus was), with my preference filling in what was not
firmly decided in the room.