Re: Obtaining a database of new functionality per Emacs version

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > Manually or automatically?  If manually, the result will be as
>> > accurate and comprehensive as NEWS.  If automatically, please tell
>> > what kind of implementation you have in mind.
>> Manually, similar to how version information is added to customizables.
> That needs Someone™ to be extra vigilant and double-check any changes
> that add functions to prod people to mark them with a version tag.  My
> experience with being that cop in defcustoms case is that the
> probability of some falling through the cracks is non-negligible.

I also doubt we'll find someone willing to take on that job.
It's a big job and we've lived with it for so many years that it's hard
to convince oneself that it's worth the trouble.

I do think it'd be useful, but I think it can be made largely automatic,
which so it requires much less work and suffers from fewer errors.

>> The gain is having a machine-readable version you can consult from a
>> Lisp program. Who knows, maybe you could use it to make an Emacs Lisp
>> spec independent implementations could target...
> I know of libraries that have this as part of their SOPs, but Emacs is
> so much larger than any library that I doubt if this scales well
> enough.  So I don't believe such manual procedures will be reliable
> enough in Emacs.  One possible idea is to have a Git commit hook that
> would reject commits with new functions if they fail to include the
> necessary tag.

Also, if we want to have this as a "dependency checker", then it'll have
to deal not just with "core ELisp" but also with all the bundled
packages, which is quite different from the usual notion of "API version".

Maybe a script that scrapes the `DEFUN`s and `DEFVAR`s from the C code,
along with the `defun`s and `defvar`s from the Lisp code would be a good
start.  Of course, loading all the Elisp files and then dumping the
`obarray` would also be another valid alternative (but this one
requires building old versions of Emacs).

We could apply that to the source for various past Emacs versions to
build a prefix-tree indicating in which version each was introduced.
We could then compress this tree by "cutting the branches" as soon as
all the leaves below map to the same version.


        Stefan