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

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

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.