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