bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>, Bastien <bzg@gnu.org>,
>  62762@debbugs.gnu.org
> Date: Tue, 11 Apr 2023 07:18:18 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Or maybe Org folks (CC'ed) could suggest a better fix.  I understand
> > the reasons for this behavior in Org, but none of the reasons
> > described in org-version.el are relevant to Emacs development, when a
> > new version of Org is merged.  Maybe the abort could be augmented not
> > to produce such a drastic effect?
> 
> The fact the Org error is triggered means that Emacs does not re-compile
> .el files that refer to macros that have been changed.

You know this is not really possible in Emacs.

> Macros not being updated, as one may expect, may break the code using
> old macro expansions. So, I cannot say that Org is wrong complaining
> about mismatch here. In fact, we already made the check less strict to
> work around the same issue on ELPA. See
> https://list.orgmode.org/orgmode/87r10ey8ov.fsf@localhost/ and
> https://list.orgmode.org/orgmode/87pmfijrvw.fsf@localhost/

How is this different from any other Lisp file in Emacs?  We have
quite a few that define macros used elsewhere, and we rely on
byte-compilation during the build to tell us when the old definitions
get in the way.  We don't forcefully abort the build, just because
problems _might_ exist.  And people who want to make sure their builds
are 110% perfect always bootstrap to begin with.  Building a tarball
also requires a bootstrap, so the chance of these issues slipping
through cracks are minuscule to say the least.

Anyway, any other words of wisdom?  Like which org/*.el files actually
need to be recompiled in this case?  Or are you saying all of them
need to be recompiled?

I also am not sure I understand the logic of this test: AFAIU it only
tests the version string, not the actual macros that might have been
changed.  Are you saying that Org bumps its version string each time
_any_ Org macro is modified?

Also, how about the alternative of including the version string in
every Org Lisp file that needs to be recompiled when the version
changes (or the macros change)?  Then recompilation will happen
automatically, and this problem will go away.  Does this make sense?

> Maybe make bootstrap is justified then?

No, it isn't.  Not unless files outside of lisp/org/ will start
importing org-version.el.

> Of course, ideally, Emacs should provide a way to handle macro dependencies.

Ideally, this would be a much nicer world, indeed.  But humanity was
expelled from the Garden of Eden long ago, so here we are.