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 kJd4N4p7oV7CGwAA0tVLHw (envelope-from ) for ; Thu, 23 Apr 2020 11:27:06 +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 UGEuApF7oV4GSwAA1q6Kng (envelope-from ) for ; Thu, 23 Apr 2020 11:27:13 +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 3C3A3940901 for ; Thu, 23 Apr 2020 11:27:12 +0000 (UTC) Received: from localhost ([::1]:41344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRa0b-0004oX-Ss for larch@yhetil.org; Thu, 23 Apr 2020 07:27:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43530) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRZzs-0004ni-Co for emacs-orgmode@gnu.org; Thu, 23 Apr 2020 07:26:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRZzr-0000At-CP for emacs-orgmode@gnu.org; Thu, 23 Apr 2020 07:26:24 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:40309) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRZzq-00007e-MU for emacs-orgmode@gnu.org; Thu, 23 Apr 2020 07:26:23 -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 A1554C000A; Thu, 23 Apr 2020 11:26:18 +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> <87ftd2zdpj.fsf@nicolasgoaziou.fr> <87a732hpiu.fsf@alphapapa.net> Mail-Followup-To: Adam Porter , emacs-orgmode@gnu.org Date: Thu, 23 Apr 2020 13:26:17 +0200 In-Reply-To: <87a732hpiu.fsf@alphapapa.net> (Adam Porter's message of "Wed, 22 Apr 2020 22:03:37 -0500") Message-ID: <87eesejvdy.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.183.198; envelope-from=mail@nicolasgoaziou.fr; helo=relay6-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/23 07:26:19 X-ACL-Warn: Detected OS = Linux 3.11 and newer [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.56400748699721]; 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.22), country: US(-0.00), ip: 209.51.188.17(-0.56)]; 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: XcUOARJ8JazE Hello, Adam Porter writes: > 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. :) [...] > 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. I think it isn't a realistic policy, because it is not even close to how Org development happens. Unlike what you write, even with a smiley, I am taking compatibility issues and breakages as seriously as I can. I do my best to not introduce them in the first place, and, if I do, because I think that's for the better, I do my best to make the transition easier. Yet, breakage happens, and I am sincerely sorry about that. Now, fire me if you want. However, please remember that Org development happens in a best effort, and in a somewhat opportunistic, fashion. Most internal changes, and therefore breakages, stem off a bug report or an enhancement request, not from a big ROADMAP file in the sky. Call it amateurism, but I think it is in its most noble meaning. Maybe in the not-so-distant future, professional-minded folks will lead the project, defining road maps, strict rules for features integration, proper issue tracking, and whatnot. And maybe that will be a good thing. Any help is welcome. Until then, we have two branches: 1. master, where breakage can happen, which implies at least minor version numbers bumps. 2. maint, where breakage is to be avoided at all cost, which implies only bugfix version number bumps. Close to a release, we also happen to have "feature-freeze" periods. In that situation, development happens in a temporary third branch: next. You may consider it to be an insufficient policy, but AFAICT, this is all we have at the moment, and, possibly, all we can afford, too. Of course, this is only my opinion. I wouldn't dare talking for other developers. AFAIC, I already do all I can, with the time I have; I cannot follow your policy. > 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. I thought most third-party breakages came from misuse of internal functions in Org. But if you say it is orthogonal, and that I am off-topic, so be it. Regards, -- Nicolas Goaziou