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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 24, 2026, 03:56 UTC
Message-ID: <xmqq4iff5ml0.fsf@gitster.g>
In-Reply-To: <5f34a5a9-9f72-b725-666a-94798895d122@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

As I wrote, after the current cycle ends at the end of this month, a 10-12 week cycle including the end-of-year slowness would mean the next cycle 2.98 will end at the end of this year. Expolation 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 between 2.99 and 3.0 needs to be some lead time for "advertisement". This lead time between 2.99 and 3.0 does not have to be the usual 8-to-12-weeks 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 distros. 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 for the breaking changes are enabled in 3.0 while they are disabled in 2.99.1. Volunteers can run 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 3.0 release in order to keep the differences between 2.99.1 and 3.0 to absolute minimum, and then remove the "dead code" that is used when WITH_BREAKING_CHANGES is not enabled from 3.X at our leasure.

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

Good enough?