Re: Release 9.3.8

[Bastien <bzg@gnu.org>]

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