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