emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Policy proposal: Do not move existing functions/macros except in major version increments
@ 2020-04-17  2:16 Adam Porter
  2020-04-17  9:03 ` Nicolas Goaziou
  2020-06-01 15:11 ` Bastien
  0 siblings, 2 replies; 7+ messages in thread
From: Adam Porter @ 2020-04-17  2:16 UTC (permalink / raw)
  To: emacs-orgmode

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-06-01 22:59 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

Code repositories for project(s) associated with this 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).