From: Bastien <bzg@gnu.org>
To: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Release 9.3.8
Date: Wed, 09 Sep 2020 10:17:28 +0200 [thread overview]
Message-ID: <878sdjmkiv.fsf@gnu.org> (raw)
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")
Hi Kévin,
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> Bastien <bzg@gnu.org> 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.
>>
>> ... 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=9.4"…).
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,
--
Bastien
next prev parent reply other threads:[~2020-09-09 8:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 15:49 Bastien
2020-09-07 17:23 ` Kévin Le Gouguec
2020-09-07 17:45 ` Bastien
2020-09-08 5:35 ` Kévin Le Gouguec
2020-09-09 8:17 ` Bastien [this message]
2020-09-10 0:45 ` Kyle Meyer
2020-09-10 6:32 ` Check for master branch from Elisp (was: Release 9.3.8) Kévin Le Gouguec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sdjmkiv.fsf@gnu.org \
--to=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=kevin.legouguec@gmail.com \
--subject='Re: Release 9.3.8' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).