Re: [PATCH 00/13] Update versions of libcurl and Perl

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 11, 2024, 18:35 UTC
Message-ID: <xmqqttdicws8.fsf@gitster.g>
In-Reply-To: <CAPig+cRmyZhq1qtomTFP7p7XMqrCP8-u7ah8D2+yUtrL880y7g@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 8 quoted lines

> I may be in the minority here, but I'm fairly negative on this entire
> patch series. As you say, supporting these old versions is effectively
> zero-cost, so how does this project benefit from these changes which
> potentially "break" Git for users on older platforms? I see no upside
> here. The cover letter provides no strong justification for
> (potentially) inconveniencing people; the argument about being able to
> utilize more modern Perl features is weak[1] at best and is not
> convincing.

While I agree with all you said above, one thing I find missing is that even with #ifdef, we won't be shipping what we tested in real, as nobody, not just the author that touches the same file with the #ifdef we added 6 months ago is in, but all other developers who looked at the change. It merely is "we have #ifdef here and those with ancient version of the library shouldn't see this new code", which certainly is good enough for those of us who consider the ancient platform support as a "best effort" thing.

But that does not, in my dictionary, quite qualify for the verb "support". A variable declared only inside #ifdef may be used outside it, or a variable declared without initialization outside that is only assigned inside #ifdef may be used after matching #endif, which would not be noticed by anybody because nobody among us would be running such an ancient version without the feature #ifdef guards.

So I dunno.

Having said all that, I did find it was surprising that we raised to a merely 6-year old cutoff point. If it were discarding versions of libraries that are older than 12 years (instead of 6 years), would you be having the same reaction?

Thanks.