Re: Minimum libCurl version for git

> 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.