From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [DEV] Bump Emacs requirement to 24.4? Date: Sat, 15 Aug 2015 12:02:40 +0200 Message-ID: <87bne8eunz.fsf@gmx.us> References: <87io8tfrtk.fsf@nicolasgoaziou.fr> <87vbctieu3.fsf@gmx.us> <20150806074217.00177cc9@zotac> <87lhdohmii.fsf@nicolasgoaziou.fr> <87bnekrfgi.fsf@gmx.us> <874mk15862.fsf@gnu.org> <87pp2povpl.fsf@nicolasgoaziou.fr> <87y4hddl2y.fsf@free.fr> <87tws1dkd3.fsf@gmx.us> <87r3n5dk0v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQYIg-0006O4-Dh for emacs-orgmode@gnu.org; Sat, 15 Aug 2015 06:02:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZQYId-0000Kj-69 for emacs-orgmode@gnu.org; Sat, 15 Aug 2015 06:02:54 -0400 Received: from plane.gmane.org ([80.91.229.3]:54542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQYIc-0000IT-Vd for emacs-orgmode@gnu.org; Sat, 15 Aug 2015 06:02:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZQYIa-00011o-ME for emacs-orgmode@gnu.org; Sat, 15 Aug 2015 12:02:48 +0200 Received: from tmo-101-50.customers.d1-online.com ([80.187.101.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Aug 2015 12:02:48 +0200 Received: from rasmus by tmo-101-50.customers.d1-online.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Aug 2015 12:02:48 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien Guerry 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 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 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