From: Adam Porter <email@example.com> To: firstname.lastname@example.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: <email@example.com> (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 ` 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Policy proposal: Do not move existing functions/macros except in major version increments' \ /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 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).