From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MAi6JloYV1+3CQAA0tVLHw (envelope-from ) for ; Tue, 08 Sep 2020 05:36:26 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QJeXIloYV18tXgAAbx9fmQ (envelope-from ) for ; Tue, 08 Sep 2020 05:36:26 +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 2472D9402CB for ; Tue, 8 Sep 2020 05:36:26 +0000 (UTC) Received: from localhost ([::1]:47222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFWIr-0003Cw-47 for larch@yhetil.org; Tue, 08 Sep 2020 01:36:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFWI6-0003Az-Ag for emacs-orgmode@gnu.org; Tue, 08 Sep 2020 01:35:38 -0400 Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:44480 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFWI4-0007hJ-P3 for emacs-orgmode@gnu.org; Tue, 08 Sep 2020 01:35:38 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kFWI1-0003MH-Sv for emacs-orgmode@gnu.org; Tue, 08 Sep 2020 07:35:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Subject: Re: Release 9.3.8 Date: Tue, 08 Sep 2020 07:35:29 +0200 Message-ID: <87h7s8kezi.fsf@gmail.com> References: <878sdl1tab.fsf@gnu.org> <87blih33i8.fsf@gmail.com> <878sdlscpr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:HpKDbHoQzjo9ioBzhAnoofnynbE= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/08 01:35:34 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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.41 X-TUID: iLDNc++1OUQf Bastien writes: >> - Will Emacs's maintenance branch (emacs-27) be updated with Org 9.3.8, >> so that Emacs 27.2 includes all bugfixes for 9.3? (If so, I can open >> a new report on Debbugs to track this, as suggested by Stefan K.) > > Yes, thanks. ACK; see bug#43268! >> - During the development of 9.4, AFAICT, while the "Version:" comment in >> org.el sayd "9.4-dev", the org-version variable matched the latest >> tag, i.e. 9.3.x. >> >> I therefore couldn't figure out a way to check for 9.4 >> programmatically. > > ... because 9.4 is not yet released - or am I missing something? See Emacs's master branch for a counter-example: even though 28.1 is not out yet, emacs-version says "28.0.50", so one can determine that they're running on the master branch. It's clearly not a big deal; cf. below. > On what commit would I add the "release_x.(y+1)-rc" on master, since > master is always moving forward? If a new major release is immediately merged to the maint branch, it would be enough to have a followup empty commit on master, and tag that. I'm not suggesting to do that though; I don't find empty commits very elegant. IIUC, for the Emacs repository, the source of truth is not the latest tag, but configure.ac's AC_INIT clause, so it takes a (decidedly non-empty) bump-commit to increase the version. See e.g. 64fe67beff. > I would like to keep things simple here: let's have annotated tags for > releases and... master. > > Let me know if I miss a very obvious use-case for a better setup. That's fair. My "use-case" was to conditionally swap RET and C-j for Org<9.4, to palliate the lack of electric-indent-mode. It's far from a critical problem, and there are other ways for me to solve this (rely on fboundp, run "make ORGVERSION=9.4"…).