Jeff King <peff@xxxxxxxx> writes: > On the other hand, I don't know how useful those deprecations are going > to be, as it depends on the timeframe. If the deprecation is added for > the same version of libcurl that implements the alternative (which is > roughly the case here), then we'd always be stuck supporting the old and > new forms (old for backwards compatibility, and new to silence the > deprecation warning). ... or just keep the warning without promoting, with "-Wno-error=...". > We care a lot more about the deprecation once the > alternative has been around for a while, and/or the old way of doing > things is about to be removed. And if we just wait until that removal, > then we do not have to rely on deprecation warnings. The build will > break just fine on its own. :) Yes and no. It is not always like "this symbol is now known under this different name", which is trivial to adjust. I briefly tried to see how IOCTL -> SEEK change should look like until I realized that the new way was invented too recently and stopped looking, but it would involve changes to the function logic in the callback functions, as the function signature---both parameters and its return values---of the callback changes. I do not want to see us scrambling to make such adjustments to the code at the last minute, so some sort of advance warning is a good thing to have. Thanks.
