Re: [PATCH 0/4] dropping support for older curl

From: Tom G. Christensen <tgc@jupiterrise.com>
Date: Aug 10, 2017, 20:33 UTC
Message-ID: <873e1f31-2a96-5b72-2f20-a5816cad1b51@jupiterrise.com>
In-Reply-To: <20170809214758.p77fqrwxanb4zn5a@sigill.intra.peff.net>

[I am resending this since the original does not seem to have made it to the list, at least I cannot find it in any archives]

On 09/08/17 23:47, Jeff King wrote:

Show 10 quoted lines

> On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
>> I mean, if we even go out of our way to support the completely outdated
>> and obsolete .git/branches/ for what is likely a single user, it may not
>> be the worst to keep those couple of #ifdef guards to keep at least
>> nominal support for older cURLs?
> 
> You've totally ignored the argument I made back then[1], and which I
> reiterated in this thread. So I'll say it one more time: the more
> compelling reason is not the #ifdefs, but the fact that the older
> versions are totally untested.

Perhaps you forgot but I stated in the original thread that I build RPMS for RHEL/CentOS 3, 4, 5, 6 and 7. I still do and I run the testsuite every single time. I currently have 2.13.3 up for el4, el5, el6 and el7. Only el4 requires any patches, the rest will build out of the box with the vendor supplied version of curl.

The plan was to drop the el4 builds for 2.14.0 to get rid of the patches.

> In fact, they do not even compile, and
> yet I have not seen any patches to fix that.
>

I just built a pristine 2.14.0 on CentOS 5 with curl 7.15.5. No problems at all neither with building nor with running the testsuite.

> So IMHO this is about being honest with users about which versions we
> _actually_ support.
>

I have no problem with you wanting to drop support for older curl releases (such as 7.15.5) but don't use the argument that it doesn't currently build and nobody cares.

Also FWIW Red Hat continues to support RHEL 5 with the Extended Life-cycle Support program until 2020-11-30.

-tgc