Subject: bug#66554: [PATCH] Add the public API of Compat to the core

From: Philip Kaludercic <[email-masked]>
Date: Thu, 11 Jan 2024 20:24:25 +0000

Stefan Monnier <[email-masked]> writes:

>> --- a/lisp/subr.el
>> +++ b/lisp/subr.el
>> @@ -6873,9 +6873,9 @@ version-separator
>>  
>>  Usually the separator is \".\", but it can be any other string.")
>>  
>> -
>>  (defconst version-regexp-alist
>> -  '(("^[-._+ ]?snapshot$"                                 . -4)
>> +  `(("^[-._+ ]?hyper$"                                    . ,most-positive-fixnum)
>> +    ("^[-._+ ]?snapshot$"                                 . -4)
>>      ;; treat "1.2.3-20050920" and "1.2-3" as snapshot releases
>>      ("^[-._+]$"                                           . -4)
>>      ;; treat "1.2.3-CVS" as snapshot release
>
> Relying on a change in `version-regexp-alist` open a can of worms.

Out of curiosity, what are you thinking about?  I know this is a hack,
but the way I though about it, it should work.

> It's much simpler to make sure the GNU ELPA `compat` package uses
> versions of the form `30.0.NN` (or `30.1.NN` if it means it
> offers functionality from Emacs-30.2, tho hopefully we'll never get
> there).

This would also be an acceptable fallback strategy IMO, with the minor
annoyance that it might confuse some people into thinking that the ELPA
package is out of date.

>>>>> Is there a place where we could add a warning to make sure that
>>>>> bumping the version won't be forgotten?
>
> The addition cab done procedurally, as in
>
>     ;;;;####autoload (push (list 'compat emacs-major-version
> emacs-minor-version) package--builtin-versions)

If this work, I like this idea a lot!  I'll test it out to see if this
could simplify things.

> -- Stefan