Re: Policy proposal: Do not move existing functions/macros except in major version increments

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Adam Porter <adam@alphapapa.net> writes:

> The relatively recent moving of org-get-outline-path to org-refile.el
> has caused breakage in Org itself in several places, e.g.

[...]

> Thankfully, Kyle has proposed a patch to revert that change.  I hope it
> is merged.
>
> If it is not, when a new Org version is released with those changes

What makes you think a new Org would be released in this situation,
without fixing it first?

> I think changes like this should not be made without very careful
> consideration of the wider implications.  These kinds of changes create
> a not-insubstantial burden on maintainers of Org-related packages to
> keep up with churn and maintain compatibility with multiple Org versions
> (which are used in the wild for years--I know of users still using Org
> 8, as well as Org 9 versions that are included with older Emacs versions
> (e.g. Emacs 26.3 is still stuck in Debian unstable, not migrating to
> testing, stable, or backports)).

[...]

> So, I propose that changes like these should not be made except in major
> version increments, e.g. this change should have been delayed until the
> release of Org 10.0.  It would be helpful for users and package authors
> if they knew that changes like these would not be made until the next
> major version increment.

FWIW, I think this is too strong a requirement.

This breakage is unfortunate, and I can hear the consequences it has on
the Org ecosystem, but, hey, it happens. Note that moving part of Org
elsewhere usually introduces less friction. This is a relatively
exceptional situation.

Master is an unstable branch, relatively open to experimentation.
Moreover, that experimentation happens before deciding if the next
release should be 10.0 or 9.4, so it wouldn't help users or package
authors.

It doesn't mean we cannot do better here. For example, I think we could
improve the way Org loads its libraries. Ideally, external libraries
should only (require 'org), and optionally, (require 'ox-*) or (require
'ol-*). Thus, changes like the one discussed here would be
implementation details. For example, "ox-hugo.el" requires directly
"ob-core.el", and now "org-refile.el", which is, IMO, a path to
troubles. It should only require "org.el".

The current situation is tricky though: "org.el" requires some libraries
(e.g., "org-key.el", "org-table.el", ...), and some libraries require
"org.el" (e.g., "org-capture.el", "org-element.el", ...). I expect
"org.el" to be the entry point for the Org package, so loading should
happen in one-way only.

This would not solve everything, but it would certainly make things
smoother for external libraries.

WDYT?

Regards,

-- 
Nicolas Goaziou