On 09/08/17 23:47, Jeff King wrote:
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
