On Tue, Apr 4, 2017 at 10:33 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <peff@xxxxxxxx> wrote: >> > 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. > > Thanks, that's a very useful bit of data. According to: > > https://access.redhat.com/support/policy/updates/errata > > RHEL5 (which as I understand it basically the same as CentOS 5 in terms > of packages). Yeah CentOS is just s/RHEL/CentOS/g across the RHEL-provided source packages. It's a way to use RHEL without paying for (or getting) RHEL support. > ended its 10-year support cycle just a few days ago. That > would perhaps make 7.20.1 a reasonable cutoff. FWIW these cut-offs don't have a lot to do with how long some installations run things like RHEL5 or CO5 actually run. RHEL5's EOP3 phase ended days ago, but the End of Extended Life-cycle Support goes until late 2020, and for anyone running the CentOS flavors these dates matter very little, since they're about how long RedHat is supporting it, and if you don't have RedHat support in the first place... > I dunno. We could also just punt on the whole thing. It was nice to see > a bunch of #ifdefs go away, but the code they're protecting is actually > not that complicated. Most of them do not have an #else at all, and we > just silently skip features on old versions. > > I think it might be nice to declare a "too old" version, though, just so > we can stop adding _new_ ifdefs. Maybe 7.11.1 is that version now, and > in another few years we can bump to 7.16.0. :) I think it's completely fine to include your patch as-is. At some point we need to pass the burden of dealing with these old software versions, saying that you should use a <10 year old library isn't unreasonable. Anyone packaging new git on RHEL5 or derivatives can just package a newer libcurl as well.