Re: [PATCH] ci: do not die on deprecated-declarations warning

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2023, 06:59 UTC
Message-ID: <xmqq4jssi8qh.fsf@gitster.g>
In-Reply-To: <Y8LjTYhTycp/tTBn@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

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

Show 5 quoted lines

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