From: Adam Porter <email@example.com>
Subject: Policy proposal: Do not move existing functions/macros except in major version increments
Date: Thu, 16 Apr 2020 21:16:24 -0500 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
If it is not, when a new Org version is released with those changes
(actually, sooner, because some users run the master branch), it will
cause further breakage in out-of-tree packages and code in user
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)).
For my own packsges, I would expect to get multiple bug reports for
several of my packages, which means that for each one, I then have to
deal with the report, make a fix, test it, log it, push it, close the
bug report...and for all that, nothing is gained. It adds up, and it's
frustrating and demoralizing.
Of course, I am not opposed, in principle, to refactoring and
reorganization of this sort. Org is a huge project, and it certainly
could benefit from these kinds of changes, in general.
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.
If this is agreeable to the Org maintainers, I'd ask that it be
documented in the project and announced in the NEWS file.
next reply other threads:[~2020-04-17 2:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 2:16 Adam Porter [this message]
2020-04-17 9:03 ` Policy proposal: Do not move existing functions/macros except in major version increments Nicolas Goaziou
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).