Re: compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables)

[Daniel Mendler <mail@daniel-mendler.de>]

On 9/9/23 14:12, Ihor Radchenko wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
>> compat-30 can be released as soon as Emacs 30 has been reasonably
>> stabilized, e.g., when the emacs-30 branch has been frozen, or a bit
>> before that. We cannot release much earlier since APIs may still change
>> and it is probably undesired to release unfinished APIs to the public
>> too early. For reference, I've created the compat-29.1.1 release around
>> the day that Eli announced the emacs-29 branch freeze.
>
> It is indeed viable to copy-paste the needed functions into the package
> code, but it _feels_ like something compat.el may provide support for.
>
> May it be possible to provide a public API in compat.el to define
> compat function versions before they appear in compat.el properly?

I see your point, but I think that Compat provides value for both
external and core packages given its current conservative approach. All
that is needed is to wait for a while after some API has been added and
Compat has been synchronized. Note that we haven't seen many API
additions in Emacs 30 so far. Compare this to compat-29.el which
provides a rich set of new APIs which are all available for external and
core packages depending on older Emacs versions.

I suggest to copy new functions temporarily to the package in question
with an fboundp check, with an additional TODO comment. We can
synchronize with Compat afterwards. Providing a public API won't work
since Compat is not included in Emacs itself. A design criterion of
Compat is also to keep the public API surface as small as possible.

Daniel