On Fri, Sep 10 2021, Daniel Stenberg wrote:
> On Fri, 10 Sep 2021, Jeff King wrote:
>
>>> The newest symbol we depend on is CURL_HTTP_VERSION_2. It was added
>>> in 7.33.0, but the CURL_HTTP_VERSION_2 alias we used was added in
>>> 7.47.0. So we could support an even older version here, but let's
>>> just correct the checked version.
>>
>> Thanks for expanding on the history here. I agree it probably
>> doesn't matter much between the two versions, as they're both 6+
>> years old (and only about 6 months apart). If somebody has a case
>> where it really matters, they can submit a patch.
>
> Forgive me for digressing a bit here but wow, I *so* appreciate your
> digging into the details of the curl history and the symbols that were
> introduced when etc. I know of no other libcurl-using project with
> this eye and sense for historic details and as the lead maintainer of
> libcurl I learn a lot here. It also keeps me motivated to provide this
> documentation and work on keeping in accurate.
>
> Keep it up! <3
Thanks! And thanks for curl.
For what it's worth I found myself looking for some bidirectional API
mapping between these option IDs and their names, we tend to prefer that
sort of pattern in git.git to macros, since we can test that something
compiles everywhere, run tests without the feature without recompiling
etc.
I found that curl didn't have anything like that & started writing up a
feature request for it, only to find that my curl.git checkout had been
on an older commit, and that you'd added that API last year in curl.git
6ebe63fac (options: API for meta-data about easy options, 2020-08-26):
https://curl.se/libcurl/c/curl_easy_option_by_name.html
It's probably not something we can use in the next 10 years, but if
whatever the most ancient OS we support upgrades past it it should make
dealing with the version-specific code in http.c even easier.
