Minimum libCurl version for git

> Going forward there are various options:
>
> 1. Do nothing - go with the status quo.
>
> 2. Correct the #ifdefs for CURLOPT_SSLKEY
>
> 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our
> minimum supported version. I feel slightly embarrassed about that, as
> that's exactly the version I have here on AIX (unless I wrest it back
> from being sysadmin-installed to being user-supported). Add a check to
> the Makefile and error if libCurl is too old.
>
> 4. Drop all current #ifdefs and one of the deprecated symbol names.
> Our minimum supported libCurl version would be 7.9.8 from Jun 2002.
>
> 5. Drop all current #ifdefs and both of the deprecated symbol names.
> Our minimum supported libCurl version would be 7.10.8 from Nov 2003.
>
> 6. Warn (not error) if libCurl is older than say the 3 years suggested
> by Daniel. This would seem to require periodic updates to the Makefile
> check.
>
> I'm happy to whip up a patch if required, but I thought a series of
> mutually-exclusive alternative patches would be confusing without
> prior agreement on the approach.
>
> Mike
>
> [1]  http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup

> Mike Ralphson <mike.ralphson@gmail.com> writes:
> 
> > Going forward there are various options:
> >
> > 1. Do nothing - go with the status quo.
> >
> > 2. Correct the #ifdefs for CURLOPT_SSLKEY
> >
> > 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our
> > minimum supported version. I feel slightly embarrassed about that, as
> > that's exactly the version I have here on AIX (unless I wrest it back
> > from being sysadmin-installed to being user-supported). Add a check to
> > the Makefile and error if libCurl is too old.
> >
> > 4. Drop all current #ifdefs and one of the deprecated symbol names.
> > Our minimum supported libCurl version would be 7.9.8 from Jun 2002.
> >
> > 5. Drop all current #ifdefs and both of the deprecated symbol names.
> > Our minimum supported libCurl version would be 7.10.8 from Nov 2003.
> >
> > 6. Warn (not error) if libCurl is older than say the 3 years suggested
> > by Daniel. This would seem to require periodic updates to the Makefile
> > check.
> >
> > I'm happy to whip up a patch if required, but I thought a series of
> > mutually-exclusive alternative patches would be confusing without
> > prior agreement on the approach.
> >
> > Mike
> >
> > [1]  http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
> 
> Thanks for a detailed analysis.
> 
> My gut feeling is we should be able to do 3 safely.
> 
> I am not sure if you are reading the "deprecated" column correctly,
> though:
> 
>  Name                           Introduced  Deprecated  Removed
> CURLINFO_HTTP_CODE              7.4.1         7.10.8
> CURLOPT_INFILE                  7.1           7.9.7
> 
> These two symbols are what we do use in our code, so the
> deprecated/removed column would give us the upper bound of the versions,
> not the lower bound.
> 
> We can have these two macro definitions on our side
> 
> 	#if curl older than 7.10.8
>         #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
> 	#endif
> 
> 	#if curl older than 7.9.7
>         #define CURLOPT_READDATA CURLOPT_INFILE
> 	#endif
> 
> for backward compatibility, while writing our code to the recent API by
> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
> curl would not have to suffer a bit.
> 
> So I think your 4 and 5 are non issues.
> 
> But this is without having a handy tally of what releases of various
> distros shipped their libcurl with.  If we had a table like this...
> 
> Distro			Last update		libcurl version
> ----------------------------------------------------------------
> Debian 3.1 sarge	2005-06-06		???
> Debian 4.0 etch		2009-02-10 (4.0r7)	7.15.5
> Debian 5.0 lenny	2009-02-14		7.18.2
> 
> ... then we could say "This is git, a tool primarily for developers to
> keep track of sources; nobody would be running on a box that was updated
> the last time four years ago, so we can safely assume libcurl more recent
> than version ???".
> 
> It would also be valid to argue that "4.0 etch may have been updated last
> month, but libcurl 7.15.5 has been available on the release a lot before
> that, as of 200X-XX-XX, which is more than N years ago, which makes it
> safe to assume that assuming 7.15.5 or later is fine for Debian folks; do
> not get fooled by the date of last update," in which case it would be good
> to have entry for the original release date.

> On Fri, 20 Mar 2009, Junio C Hamano wrote:
>
>> For non-commercial Linux folks I think it should be Ok to assume not
>> too ancient libcurl, but I have no clue on how the table like the
>> above would look like for things like AIX, IRIX, HPUX etc.  ... Oh,
>> and SCO.
>
> The oldest libcurl version I know is still being distributed to and
> therefor used by people is one IBM provides for AIX, and that is 7.9.3
> - dated "Jan 23 2002".

> We can have these two macro definitions on our side
>
>        #if curl older than 7.10.8
>        #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
>        #endif
>
>        #if curl older than 7.9.7
>        #define CURLOPT_READDATA CURLOPT_INFILE
>        #endif
>
> for backward compatibility, while writing our code to the recent API by
> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
> curl would not have to suffer a bit.

> 2009/3/20 Junio C Hamano <gitster@pobox.com>:
>> We can have these two macro definitions on our side
>>
>>        #if curl older than 7.10.8
>>        #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
>>        #endif
>>
>>        #if curl older than 7.9.7
>>        #define CURLOPT_READDATA CURLOPT_INFILE
>>        #endif
>>
>> for backward compatibility, while writing our code to the recent API by
>> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
>> curl would not have to suffer a bit.
>
> See? That's why they pay you the big maintainer-bucks... 8-)

> According to Daniel's list [1], CURLOPT_SSLKEY was introduced in 7.9.3, but 
> we enable it in http.c if we see version >= 7.9.2. This could be a typo in 
> the haxx.se list, or the option could have been available in (some) 7.9.2 
> releases, or it could be a git bug. Again, not one which appears to be 
> biting anyone.