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

[Daniel Mendler]

Stefan Monnier <monnier@iro.umontreal.ca> 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.
> 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).

I had also considered to use versions like 29.0, 30.0, etc. for Compat.
However this is unfortunately not what we have done for Compat so far. I
argue that such versions are more confusing for package developers. If
developers want to depend on Emacs 30.1 features, it is more natural to
require (compat "30.1") in the package header.

If you don't want to use `version-regexp-alist' what about my initial
proposal of specifying a version like 30.1.9999 in the header of
compat.el?

Daniel