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 XNDEBV6I1V4UIgAA0tVLHw (envelope-from ) for ; Mon, 01 Jun 2020 22:59:42 +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 8BEvAV6I1V7YYgAA1q6Kng (envelope-from ) for ; Mon, 01 Jun 2020 22:59:42 +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 406EA94030A for ; Mon, 1 Jun 2020 22:59:41 +0000 (UTC) Received: from localhost ([::1]:35596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jftP8-00025j-Vf for larch@yhetil.org; Mon, 01 Jun 2020 18:59:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jftOn-00025S-49 for emacs-orgmode@gnu.org; Mon, 01 Jun 2020 18:59:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59262) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jftOl-0004Iu-9H; Mon, 01 Jun 2020 18:59:15 -0400 Received: from lns-bzn-32-82-254-31-120.adsl.proxad.net ([82.254.31.120]:51104 helo=guerry) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1jftOj-0003ih-4E; Mon, 01 Jun 2020 18:59:14 -0400 Received: by guerry (Postfix, from userid 1000) id B533A1A605CD; Tue, 2 Jun 2020 00:59:10 +0200 (CEST) From: Bastien To: Adam Porter Subject: Re: Policy proposal: Do not move existing functions/macros except in major version increments Organization: GNU References: <87blnqx3ev.fsf@alphapapa.net> <87eeqyes8h.fsf@bzg.fr> Date: Tue, 02 Jun 2020 00:59:10 +0200 In-Reply-To: (Adam Porter's message of "Mon, 1 Jun 2020 13:07:23 -0500") Message-ID: <87a71ms88x.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 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-Spam-Score: 0.49 X-TUID: diPYSBcvoDAr Hi Adam, Adam Porter writes: > I mostly agree with you. My request is simply that, when a change > has the potential to break third-party packages, and it's a change, > such as this one, that mostly moves code around for organizational > purposes, that it be delayed until the next major version. IIRC this was the case for the change that triggered your first email, it was in master, no? > My goal for such a policy would be to reduce the frequency of such > changes that third-party package authors have to write compatibility > code for. The (if (version< org-version ...)) workarounds become > confusing for authors and users, and somewhat of a maintenance > burden. I understand the burden. We don't really follow the conventions of semantic versioning. We use "x.y.z" versions with z being for bugfix releases and both y and x for... the rest. Because we are slow at releasing so-called minor releases, they end up containing some changes that users and developers should be aware of. Hence the need to let them know about such changes. I don't think using a policy will help here, because definitions of "breaking" may vary: is a change in a function's signature always a breaking change? For every function? Or just for core functions? If so, which ones? (See the many discussions in the npm universe about what to consider a breaking change and worth a major release.) In a word: even though stricter rules could somehow help, I do think the main issue is about *communication*, not conventions. > That's a very clever way to do it! Thanks for your work on this. Thanks, I hope it will be useful. > If > it's feasible, you might also consider allowing committers to put such > a header in the git commit log and parsing it out of that, which could > make it even easier. The idea is that updates that are important enough to be listed on updates.orgmode.org are the ones that *should* be somehow announced on the mailing list. If we let updates.orgmode.org monitor commits, then people who are only reading the list will miss updates (which we don't want, I think.) That said, it would be nice to have a function that checks the data from https://updates.orgmode.org/data/updates and warn the user when there is a new upcoming change. -- Bastien