On Fri, Mar 20, 2009 at 02:44:16PM -0700, Junio C Hamano wrote: > Mike Ralphson <mike.ralphson@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
