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