Release 9.3.8

Release 9.3.8

[Bastien]

Hi all,

I'm releasing Org 9.3.8, a bugfix release.

Enjoy!

The next release will be 9.4: if you have outstanding important bugs
you would like to point to or to report, please go ahead.

Thanks,

-- 
 Bastien

Re: Release 9.3.8

[Kévin Le Gouguec]

Bastien <bzg@gnu.org> writes:

> Hi all,
>
> I'm releasing Org 9.3.8, a bugfix release.
>
> Enjoy!

Thanks for this release 🎉

> The next release will be 9.4: if you have outstanding important bugs
> you would like to point to or to report, please go ahead.

No bug to report, however I've got a couple of questions wrt. versions:

- Once 9.4 is released, will the maint branch be updated to this
  version?

- 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.)

- 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.  Would it make sense to:

    - set a "release_x.(y+1)-rc" tag on master once version "x.y" is
      released and goes in the maint branch,

    - in targets.mk, when computing ORGVERSION, add "--first-parent" to
      "git describe", so that org-version matches this rc-tag when
      compiling Org's master branch?

At any rate, thanks for all the work.

Re: Release 9.3.8

[Bastien]

Hi Kévin,

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> - Once 9.4 is released, will the maint branch be updated to this
>   version?

Yes.  See https://orgmode.org/worg/org-maintainance.html

> - 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.

> - 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?

> Would it make sense to:
>
>     - set a "release_x.(y+1)-rc" tag on master once version "x.y" is
>       released and goes in the maint branch,
>
>     - in targets.mk, when computing ORGVERSION, add "--first-parent" to
>       "git describe", so that org-version matches this rc-tag when
>       compiling Org's master branch?

On what commit would I add the "release_x.(y+1)-rc" on master, since
master is always moving forward?

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.

-- 
 Bastien

Re: Release 9.3.8

[Kévin Le Gouguec]

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!

>> - 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"…).

Re: Release 9.3.8

[Bastien]

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

Re: Release 9.3.8

[Kyle Meyer]

Bastien writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>>> - 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."

Can't you inspect the return value of org-git-version?  (Though in my
view, distinguishing based on the functionality present with things like
fboundp, which you mention below, is typically a better approach, if
possible.)

Check for master branch from Elisp (was: Release 9.3.8)

[Kévin Le Gouguec]

Kyle Meyer <kyle@kyleam.com> writes:

> Can't you inspect the return value of org-git-version?

That can work out, though unless I'm missing something, I need to move
to the org-mode repository, ask "git branch --contains", and parse the
output.  Possible, but somewhat involved.

(TIL: git-describe's "{tag}-{nbcommits}-g{hash}" is actually a valid
revision format that other Git commands understand.)


For the sake of completeness, I've tried visiting org.el and evaluating

    (package-desc-version (package-buffer-info))

but package-buffer-info ends up calling (version-to-list "9.4-dev"),
which chokes on "-dev".  FWIW, that can be worked around with:

    (add-to-list 'version-regexp-alist (cons "^-dev$" -1))

>                                                         (Though in my
> view, distinguishing based on the functionality present with things like
> fboundp, which you mention below, is typically a better approach, if
> possible.)

Right, that's my conclusion as well :)