Re: Minimum libCurl version for git

[Junio C Hamano <gitster@pobox.com>]

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.

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.