From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gPX8Bc8FoV7lCwAA0tVLHw (envelope-from ) for ; Thu, 23 Apr 2020 03:04:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id uOlABNUFoV69WgAA1q6Kng (envelope-from ) for ; Thu, 23 Apr 2020 03:04:53 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 49F2E940D79 for ; Thu, 23 Apr 2020 03:04:52 +0000 (UTC) Received: from localhost ([::1]:33104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRSAV-0003he-9k for larch@yhetil.org; Wed, 22 Apr 2020 23:04:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40106) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRS9Y-0003hO-Od for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 23:03:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRS9Y-0001WX-2O for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 23:03:52 -0400 Received: from ciao.gmane.io ([159.69.161.202]:35932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRS9W-0001S0-BP for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 23:03:51 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jRS9T-000H1Q-7o for emacs-orgmode@gnu.org; Thu, 23 Apr 2020 05:03:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Adam Porter Subject: Re: Policy proposal: Do not move existing functions/macros except in major version increments Date: Wed, 22 Apr 2020 22:03:37 -0500 Message-ID: <87a732hpiu.fsf@alphapapa.net> References: <87blnqx3ev.fsf@alphapapa.net> <87ftd2zdpj.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Received-SPF: pass client-ip=159.69.161.202; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/22 22:47:34 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Received-From: 159.69.161.202 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: -0.61 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [-0.61 / 13.00]; GENERIC_REPUTATION(0.00)[-0.5642203767405]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.22), country: US(-0.00), ip: 209.51.188.17(-0.56)]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[209.51.188.17:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_NEQ_ENVFROM(0.00)[adam@alphapapa.net,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; URIBL_BLOCKED(0.00)[nicolasgoaziou.fr:email,alphapapa.net:email]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[alphapapa.net]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: M4on6i1Cbw96 Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Adam Porter 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 don't know what will happen. I don't know whether the Org maintainers would consider the problem serious enough to avert (as you said later, "it happens"). That's why I pointed out what the consequences would be if the patch isn't merged, to encourage its merging. >> 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. Of course, I am biased here, but I feel like it's not quite as exceptional as it ought to be. The more Org-related packages I make and maintain, the more version-specific workarounds I have to add due to changed function names, signatures, etc. These are sometimes necessary, of course, but I think they should be made more carefully and deliberately. Of course, Org doesn't make any promises to third-party packages. But that is the issue, isn't it? I'm saying that I think it should start taking this issue a little more seriously. :) > 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. That is a matter of policy, which is what I'm proposing. When such a change is desired (symbol name, function signature, etc), it should be targeted at the next major version increment. If the project as a whole is not ready to make that increment, that change should be delayed until then--it can be developed in a branch and merged when preparing the major release. These kinds of changes could even be documented in advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call it, which would be more explicit and referenceable than merely a mailing list post. > 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? That is a good idea, and one that needs addressing. I'd be glad to give some feedback on it, but in a separate thread, please, because it seems like a different matter from the issue I'm raising and the proposal I'm making. Thanks, Adam