On Sun, Dec 24, 2023, 18:32 Eli Zaretskii <
eliz@gnu.org> wrote:
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, luangruo@yahoo.com, raman@google.com,
> joaotavora@gmail.com, emacs-devel@gnu.org
> Date: Sun, 24 Dec 2023 16:59:11 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > But such breakage happens at times anyway, when some macros change in
> > incompatible ways and files that have the old versions of those macros
> > compiled into them are not recompiled. It isn't anything new for
> > people who regularly update from Git and rebuild Emacs.
>
> The main problem is that with org-assert-version, "from time to time"
> becomes more frequent as the breakage is guaranteed every time a new
> version of Org is installed into Emacs tree.
If org-assert-version is the source of breakage, then that's not the
breakage I was talking about. I was talking about breakage due to
changes in macros that were the motivation for you to introduce
org-assert-version in the first place.
IOW, instead of _inducing_ a breakage via org-assert-version, you
should let stuff break by itself, when an incompatible change is made
in one of the macros which org-assert-version protects.
Exactly the point I was trying to make.
org-assert-version shouldn't become part of the problem.
The breakage due to incompatible changes can be tackled one by one, with certain programming techniques like the one I exemplified with real Org code, until they are eradicated or become very infrequent.
I've used that technique tens if not hundreds of times. It's very effective for precisely this problem, which affects not only Emacs and Elisp but any large Lisp program. The efficiency argument levied against it only very rarely holds water.
João