From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id uiRQE9iPWF/ZYwAA0tVLHw (envelope-from ) for ; Wed, 09 Sep 2020 08:18:32 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0L3bDtiPWF93dwAAB5/wlQ (envelope-from ) for ; Wed, 09 Sep 2020 08:18:32 +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 B99DB9403A7 for ; Wed, 9 Sep 2020 08:18:31 +0000 (UTC) Received: from localhost ([::1]:39042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFvJF-0001t1-Og for larch@yhetil.org; Wed, 09 Sep 2020 04:18:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFvIL-0001X0-LS for emacs-orgmode@gnu.org; Wed, 09 Sep 2020 04:17:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57805) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFvIJ-0003kn-Ac; Wed, 09 Sep 2020 04:17:31 -0400 Received: from lns-bzn-32-82-254-31-120.adsl.proxad.net ([82.254.31.120]:36450 helo=guerry) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1kFvIH-0007w6-W7; Wed, 09 Sep 2020 04:17:30 -0400 Received: by guerry (Postfix, from userid 1000) id 3ACE81A60D39; Wed, 9 Sep 2020 10:17:28 +0200 (CEST) From: Bastien To: =?utf-8?Q?K=C3=A9vin?= Le Gouguec Subject: Re: Release 9.3.8 Organization: GNU References: <878sdl1tab.fsf@gnu.org> <87blih33i8.fsf@gmail.com> <878sdlscpr.fsf@gnu.org> <87h7s8kezi.fsf@gmail.com> Date: Wed, 09 Sep 2020 10:17:28 +0200 In-Reply-To: <87h7s8kezi.fsf@gmail.com> (=?utf-8?Q?=22K=C3=A9vin?= Le Gouguec"'s message of "Tue, 08 Sep 2020 07:35:29 +0200") Message-ID: <878sdjmkiv.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: -1.01 X-TUID: fEWK0+ltx1rC Hi K=C3=A9vin, K=C3=A9vin Le Gouguec writes: > 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! Thanks! >>> - 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.=20=20 >> >> ... 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. Well, yes, but I find that confusing: "I'm using the 28.0.50 version, which looks like an officially released version, while it's not." > 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. Me neither. > 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=3D9.4"=E2=80=A6). OK - let's see if others have similar needs, and maybe we can think about this again. (Also, Kyle has more git-fu that me, so he may be in a better position to decide on this.) Thanks, --=20 Bastien