Bastien Guerry <b...@gnu.org> writes: > We can also simply revert those change and wait for the decision > to be taken. This is a matter of waiting ~10 days I'd say. > >> Also, Emacs 24.3 was released in March, 2013. By the time the next Org is >> released, it will be more than 3 years old. > > Com'on :) > > I'm back for good and don't plan to wait years between releases. > I wish we can release 8.4 at the end of August and 9.0 in October.
It was not meant as 'finger-pointing'. Slow releases are not necessarily a bad thing. Org is very important to the work of some folks, so a slow cycle might be less disruptive. OTOH, so could frequent releases... I don't know, really. Achim Gratz <strom...@nexgo.de> writes: > Nicolas Goaziou writes: >> Just to be sure, can we require Emacs 24.4 for development version >> (a.k.a. Org 8.4)? As a data point, Debian stable provides it. > > Debian Squeeze LTS or whatever they call it doesn't w/o backports. > RHEL6 doesn't have it w/o epel (RHEL7 has 24.3 IIRC). > RaspberryPi doesn't have it. I have Emacs 24.4 on my Debian Wheezy which is pretty old. Can ELPA serve different versions based on the client? > I'm still falling over Emacs 22 in various forms and Emacs 23, where it > is standard is not always at the latest version (23.4). If ELPA can (0) be used with Emacs-23 and (1) ELPA is smart enough to serve the right version of Org, I don't think this is a problem. >> Also, what is the status of XEmacs support? AFAIU Org 8.3 doesn't build >> on XEmacs but no one is complaining. We may as well drop it and ignore >> most of "org-compat.el". > > I've been doing a lot of this compat stuff, but I gave up since I > couldn't get ERT to work on XEmacs. Org did build (with lots of errors) > until some point and it was at least superficially usable. The two > XEmacs users on this list have never responded to any requests for > further testing. So I guess that XEmacs can be considered > unsupportable. And THESE are the hidden dependency when targeting older Emacs. We have so many org-prefixed functions that have equivalents in cl-lib. Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> We don't need to complete the whole 8.x series and may jump to 9.0 >> soonish, but for the time being, I suggest you create a 9.0 branch >> with the 24.3 requirement and changes that cannot go without it. >> >> WDYT? > > I think it is a mistake. > > Handling two development branches means people testing Org have to > choose which branch to test. We don't have the manpower to waste testing > capabilities like that. > > I also see no reason to write outdated code (e.g., new libraries without > lexical binding) and update it later. I agree strongly with the above. Rasmus -- Dobbelt-A
