Re: Preparing for a Git 2.26.3 release

From: Junio C Hamano <gitster@pobox.com>
Date: May 9, 2020, 17:11 UTC
Message-ID: <xmqqwo5luj6r.fsf@gitster.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.2005090903560.56@tvgsbejvaqbjf.bet>

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

Show 9 quoted lines

> On Fri, 8 May 2020, Junio C Hamano wrote:
>
>>  * Recent updates broke parsing of "credential.<url>.<key>" where
>>    <url> is not a full URL (e.g. [credential "https://"] helper = ...)
>>    stopped working, which has been corrected.
>>    (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).
>>    (merge cd93e6c029 js/partial-urlmatch later to maint).
>
> Are you planning on also releasing, say, v2.23.4, with this fix?

Yes, some subset of the changes we will apply to 2.26.3 probably can be backported down to older maintenance releases.

Our usual policy is not to backport beyond two or three maintenance tracks unless it is a security fix, and because the current maint track is 2.26.x, which means 2.25.x and possibly 2.24.x series are the oldest candidates.

If you think it makes sense to start the discussion to choose that absolute minimum set, I am fine with that approach, too. The partial-urlmatch topic was designed to be usable with tracks as old as 2.17.x series, so I am OK to go a bit further back but if we are to do so, how far back should we as the upstream go back? I am OK to say we make the 2.23 series as the oldest for this round.

And then if we were to draw the line there, what other changes in the set do we want to include the 2.{23,24,25,26}.x maintenance releases? That would certainly be a narrower subset than the list in the message you are responding to.

Thanks.