emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
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: <87blnqx3ev.fsf@alphapapa.net> (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.

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html

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
(actually, sooner, because some users run the master branch), it will
cause further breakage in out-of-tree packages and code in user
configurations.

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.

Thanks,
Adam

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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87blnqx3ev.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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).