From: Nicolas Goaziou <firstname.lastname@example.org>
To: Adam Porter <email@example.com>
Subject: Re: Policy proposal: Do not move existing functions/macros except in major version increments
Date: Fri, 17 Apr 2020 11:03:20 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Adam Porter's message of "Thu, 16 Apr 2020 21:16:24 -0500")
Adam Porter <firstname.lastname@example.org> 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
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
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.
next prev parent reply other threads:[~2020-04-17 9:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 2:16 Policy proposal: Do not move existing functions/macros except in major version increments Adam Porter
2020-04-17 9:03 ` Nicolas Goaziou [this message]
2020-04-23 3:03 ` Adam Porter
2020-04-23 11:26 ` Nicolas Goaziou
2020-06-01 15:11 ` Bastien
2020-06-01 18:07 ` Adam Porter
2020-06-01 22:59 ` Bastien
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).