From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [DEV] Bump Emacs requirement to 24.4? Date: Wed, 19 Aug 2015 18:11:58 +0200 Message-ID: <87si7f2r75.fsf@Rainer.invalid> 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> <87oai4w69i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS5yR-0005FP-Pr for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 12:12:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS5yL-0003Qy-QG for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 12:12:23 -0400 Received: from plane.gmane.org ([80.91.229.3]:38189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS5yL-0003Qq-JO for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 12:12:17 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZS5yE-0008BJ-Mn for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 18:12:10 +0200 Received: from p54b4769b.dip0.t-ipconnect.de ([84.180.118.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Aug 2015 18:12:10 +0200 Received: from Stromeko by p54b4769b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Aug 2015 18:12:10 +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 writes: > Here is my decision on this issue: > > - the Org 8.x series will be Emacs 23+ compatible. …and we should maybe do an 8.4 final release before it is frozen, but not drag it along furhter like you suggested in emacs-devel. > - the Org 9.x series will be Emacs 24.3+ compatible. > > Emacs 23 and XEmacs support will be officially dropped as of Org 9.0. Org on XEmacs is practically dead already, so why do we need to pretend it is still supported? You can check when I did the last compatibility fixes for it, after that nobody (not even any XEmacs user) has ever made any mention of it working or not working even though there were numerous changes that are unlikely to work or work correctly on XEmacs. > The maint branch continues to be used to work on minor releases, as it > has always been used. > > Instead of reverting changes from the master branch (you clearly don't > want to do that, and I don't either), I suggest we create a new branch > called "org-8-master" for Org 8.4+, and continue to use master for Org > 9.x+ (i.e. "major major releases"). I'm not sure how you want to implement this in practise, but it looks too complicated and error-prone. My suggestion would be to keep the maint branch compatible with Emacs23 until 8.4 and then (maybe) split off a maint-23 branch for any bugfixes. If a (new) maintainer springs into action to backport features into this branch, then fine, but otherwise it stops being connected to the development branches. > This is temporary: once the 9.0 version is released, we can simply use > maint and master as before, and delete org-8-master. You mustn't delete public branches. > The reason for this is that we need to make room for new features in > the 8.x series, so that these new features will be available to the > Emacs 23 users. > > If we drop Emacs 23 support as of Org 8.4, we won't be able to add new > features (e.g. new export backends) for Emacs 23. I don't think we should. Emacs23 does not get any new features, then why should Org on Emacs23 do? > I recognize having the manpower to watch after those branches might be > an issue, but we can overcome it by calling for careful testing before > major releases. See the above proposal which minimizes that impact. Call for a new maintainer for maint-23 and see if someone volunteers. Otherwise just freeze that branch and backport only fixes for really bad issues. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada