From: Nicolas Goaziou <firstname.lastname@example.org> To: Adam Porter <email@example.com> Cc: firstname.lastname@example.org 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: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> (Adam Porter's message of "Thu, 16 Apr 2020 21:16:24 -0500") Hello, Adam Porter <email@example.com> 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 exceptional situation. 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 authors. 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. WDYT? Regards, -- Nicolas Goaziou
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 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
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 \ --email@example.com \ --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).