* Release 9.3.8 @ 2020-09-07 15:49 Bastien 2020-09-07 17:23 ` Kévin Le Gouguec 0 siblings, 1 reply; 7+ messages in thread From: Bastien @ 2020-09-07 15:49 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Release 9.3.8 2020-09-07 15:49 Release 9.3.8 Bastien @ 2020-09-07 17:23 ` Kévin Le Gouguec 2020-09-07 17:45 ` Bastien 0 siblings, 1 reply; 7+ messages in thread From: Kévin Le Gouguec @ 2020-09-07 17:23 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Release 9.3.8 2020-09-07 17:23 ` Kévin Le Gouguec @ 2020-09-07 17:45 ` Bastien 2020-09-08 5:35 ` Kévin Le Gouguec 0 siblings, 1 reply; 7+ messages in thread From: Bastien @ 2020-09-07 17:45 UTC (permalink / raw) To: Kévin Le Gouguec; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Release 9.3.8 2020-09-07 17:45 ` Bastien @ 2020-09-08 5:35 ` Kévin Le Gouguec 2020-09-09 8:17 ` Bastien 0 siblings, 1 reply; 7+ messages in thread From: Kévin Le Gouguec @ 2020-09-08 5:35 UTC (permalink / raw) To: emacs-orgmode 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"…). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Release 9.3.8 2020-09-08 5:35 ` Kévin Le Gouguec @ 2020-09-09 8:17 ` Bastien 2020-09-10 0:45 ` Kyle Meyer 0 siblings, 1 reply; 7+ messages in thread From: Bastien @ 2020-09-09 8:17 UTC (permalink / raw) To: Kévin Le Gouguec; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Release 9.3.8 2020-09-09 8:17 ` Bastien @ 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 0 siblings, 1 reply; 7+ messages in thread From: Kyle Meyer @ 2020-09-10 0:45 UTC (permalink / raw) To: Bastien, Kévin Le Gouguec; +Cc: emacs-orgmode 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.) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Check for master branch from Elisp (was: Release 9.3.8) 2020-09-10 0:45 ` Kyle Meyer @ 2020-09-10 6:32 ` Kévin Le Gouguec 0 siblings, 0 replies; 7+ messages in thread From: Kévin Le Gouguec @ 2020-09-10 6:32 UTC (permalink / raw) To: Kyle Meyer; +Cc: Bastien, emacs-orgmode 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 :) ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-09-10 6:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-07 15:49 Release 9.3.8 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 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
Code repositories for project(s) associated with this public 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).