Re: Dealing with obsoletion warnings in non-core code

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 28 Sep 2020 20:34:57 +0200
> From: Vasilij Schneidermann <mail@vasilij.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> >   (if (> emacs-major-version NN)
> >     (defun recommended-function (...)
> >       ...))
> 
> You don't want a third-party package defining a potentially
> non-conformant version of future built-in functionality

We've been using such shims in packages that supported both Emacs and
XEmacs, for eons.  I don't see how it's suddenly so wrong.

> (for example if they take the definition from a specific Emacs
> version and it changes in another one)

That's a separate problem, and will happen even if you only support
versions where the function is available.  It's why we try very hard
not to make backward-incompatible changes in public APIs.

> Besides, isn't the logic the wrong way around?  The recommended function
> is something available in a newer Emacs version, so you'd test for an
> older one and if the check is positive, define the shim.

You assume that the older one is removed?  That usually doesn't
happen.

> Assuming you can even, some functionality cannot be backported that
> easily.

If the functionality cannot be had at all, there's no problem: just
provide a no-op function by that name.

Anyway, you asked how to avoid warning messages, and I suggested a way
which should do that.  If that's not what you want, fine; I tried to
help you.