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 0DmQMwFxmV7nTAAA0tVLHw (envelope-from ) for ; Fri, 17 Apr 2020 09:04:01 +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 qIZOLQVxmV4UaQAA1q6Kng (envelope-from ) for ; Fri, 17 Apr 2020 09:04:05 +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 93BB7942009 for ; Fri, 17 Apr 2020 09:04:01 +0000 (UTC) Received: from localhost ([::1]:44246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPMum-0006Xq-NN for larch@yhetil.org; Fri, 17 Apr 2020 05:04:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55534) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPMuH-0006Xf-GJ for emacs-orgmode@gnu.org; Fri, 17 Apr 2020 05:03:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPMuE-0006Vg-RH for emacs-orgmode@gnu.org; Fri, 17 Apr 2020 05:03:28 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:59069) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jPMuE-0006OB-LO for emacs-orgmode@gnu.org; Fri, 17 Apr 2020 05:03:26 -0400 X-Originating-IP: 185.131.40.67 Received: from localhost (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 7BC13C0019; Fri, 17 Apr 2020 09:03:22 +0000 (UTC) From: Nicolas Goaziou To: Adam Porter Subject: Re: Policy proposal: Do not move existing functions/macros except in major version increments References: <87blnqx3ev.fsf@alphapapa.net> Mail-Followup-To: Adam Porter , emacs-orgmode@gnu.org Date: Fri, 17 Apr 2020 11:03:20 +0200 In-Reply-To: <87blnqx3ev.fsf@alphapapa.net> (Adam Porter's message of "Thu, 16 Apr 2020 21:16:24 -0500") Message-ID: <87ftd2zdpj.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.183.198 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: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: -1.11 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 [-1.11 / 13.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GENERIC_REPUTATION(0.00)[-0.57389046516278]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.26), country: US(-0.01), ip: 209.51.188.17(-0.57)]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; RCPT_COUNT_TWO(0.00)[2]; 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)[mail@nicolasgoaziou.fr,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; URIBL_BLOCKED(0.00)[alphapapa.net:email]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[nicolasgoaziou.fr]; HAS_LIST_UNSUB(-0.01)[]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: Lx3Zouqdd4DF 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 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