On Sat, Jan 14, 2023 at 10:59:18PM -0800, Junio C Hamano wrote: > 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=...". I'm pretty strongly against that solution for anything long-term. Having to see those warnings is not only ugly, but it's confusing and trains people to ignore them (and many times I've noticed ugly warnings floating by and realized that oops, I had temporarily disabled -Werror because I had been working with some older code). > > 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. True. I do think the IOCTL/SEEK one is old enough that we can do, though. The deprecation is newer, but the SEEK interface was added in an old enough version. -Peff
