Re: [RFC] dropping support for ancient versions of curl

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 4, 2017, 08:17 UTC
Message-ID: <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>
In-Reply-To: <20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net>

On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <peff@peff.net> wrote:

Show 10 quoted lines

> My feeling is that this is old enough to stop caring about. Which means
> we can drop some of the #ifdefs that clutter the HTTP code (and there's
> a patch at the end of this mail dropping support for everything older
> than 7.11.1). But that made wonder: how old is too old? I think it's
> nice that we don't force people to upgrade to the latest version of
> curl. But at some point, if you are running a 13-year-old version of
> libcurl, how likely are you to run a brand new version of Git? :)
>
> If we declared 7.16.0 as a cutoff, we could unconditionally define
> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.

I don't object to this patch, but just as a general comment, in enterprise-y environments using an old OS (e.g. CentOS 5/6) & then compiling some selected packages like git based on OS libraries is quite common.

E.g. at work we're running git 2.12.0 compiled against CentOS 6 libraries, which has curl 7.20.1, released on Apr 14 2010. Not so long ago we were still running CentOS 5 which comes with 7.15.5 released in Aug 7 2006 which would break with your patch.

Whether we support that is another question, I think it's reasonable to say that if you're compiling git on such an old system you also need to compile a libcurl instead of using the OS version. I just wanted to point out that this *does* happen, someone is going to be compiling new git releases on CentOS 5 & will be hit by this.