Re: Release 9.3.8
Bastien writes: > Kévin Le Gouguec writes: > >> Bastien 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.)
Re: Release 9.3.8
Hi Kévin, Kévin 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. >> >> ... 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
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! >> - 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
Hi Kévin, Kévin Le Gouguec 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
Bastien 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.
