Minimum libCurl version for git

Minimum libCurl version for git

[Mike Ralphson]

See $gmane/112765 for background.

Git uses 31 CURL_, CURLINFO and CURLOPT symbols, two of these
(CURLINFO_HTTP_CODE and CURLOPT_INFILE) are officially deprecated, but
only because they have been renamed in 'recent' versions.

We protect the usage of symbols introduced in version 7.9.2 and later
with #ifdefs. These date back to some time in 2005 when those versions
of libCurl were 3 or so years old.

We use CURLOPT_FTP_USE_EPSV unprotected, which was introduced in
version 7.9.2. This is something of a pity as it is an optional
configuration item which is probably not widely used (I don't think I
knew there was any support for git over ftp). Still, 7.9.2 was a long
time ago (Dec 2001), and no-one is complaining. Disregarding this, we
would be able to use libCurl versions as far back as 7.8.1 (Aug 2001),
bugs, security fixes and performance notwithstanding.

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.

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

Re: Minimum libCurl version for git

[Junio C Hamano]

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.

Re: Minimum libCurl version for git

[Mike Hommey]

On Fri, Mar 20, 2009 at 02:44:16PM -0700, Junio C Hamano wrote:
> 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.

Original release date for etch is 2007-04-08.
Sarge was released with libcurl 7.13.2.
Woody, which was Debian 3.0, and can be considered dead already, was
released on 2002-07-19 with libcurl 7.9.5.

Mike

Re: Minimum libCurl version for git

[Daniel Stenberg]

On Fri, 20 Mar 2009, Mike Ralphson wrote:

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

I double-checked now against the changelog and it confirms that the info is 
correct in that file: CURLOPT_SSLKEY was introduced in 7.9.3. It was first 
released in a pre-release Jan 8th 2002.

I'd assume that very few git-builders have such an old libcurl installed...

-- 

  / daniel.haxx.se

Re: Minimum libCurl version for git

[Daniel Stenberg]

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

-- 

  / daniel.haxx.se

Re: Minimum libCurl version for git

[Junio C Hamano]

Daniel Stenberg <daniel@haxx.se> writes:

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

Thanks for the definitive words, Daniel.

Mike, I'd say we declare 7.9.3 as the floor and go from there.  That's
your #3, I think.

Re: Minimum libCurl version for git

[Mike Ralphson]

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

> Mike, I'd say we declare 7.9.3 as the floor and go from there.  That's
> your #3, I think.

Short patch series to follow, though maybe not today.

Mike

Re: Minimum libCurl version for git

[Junio C Hamano]

Mike Ralphson <mike.ralphson@gmail.com> writes:

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

The big maintainer-buck is called zero cents.  I am only paid with the
freedom to spend 20% of my day-job time on git [*1*].

In any case, "Write to the latest API, support older platforms with
backward compatibility wrapper as necessary" is a good practice employed
by many successful projects, including the kernel, and I think it would
apply here nicely.

>> Mike, I'd say we declare 7.9.3 as the floor and go from there.  That's
>> your #3, I think.
>
> Short patch series to follow, though maybe not today.

Thanks.

[Footnote]

*1* ... which is still generous of my employer and NEC, given the current
economic climate, but I wouldn't exactly call that "big bucks" ;-).