From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aaron Ecay <aaronecay@gmail.com>
Subject: Re: Sync up the org in emacs master to org maint branch?
Date: Tue, 31 Jan 2017 23:19:19 +0000
Message-ID: <87inou7r7s.fsf@trex>
References: <CAFyQvY16F7Vn0Wa=qV1g+HWWLV0cT7FaixLN8w7sJEAWJz9P3Q@mail.gmail.com>
	<m2o9yp4qzn.fsf@newartisans.com> <87k29d7zvw.fsf@engster.org>
	<m27f5cedxw.fsf@newartisans.com> <87fuk08i01.fsf@engster.org>
	<m27f5cxlk9.fsf@RFC1918.na.baesystems.com> <m3k29bjomb.fsf@stories>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
In-Reply-To: <m3k29bjomb.fsf@stories>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>, David Engster <deng@randomsample.de>
Cc: Bastien Guerry <bzg@gnu.org>, Kaushal Modi <kaushal.modi@gmail.com>, Phillip Lord <phillip.lord@russet.org.uk>, emacs-org list <emacs-orgmode@gnu.org>, Emacs developers <emacs-devel@gnu.org>
List-Id: emacs-orgmode.gnu.org

Hi Lars,

2017ko urtarrilak 31an, Lars Ingebrigtsen-ek idatzi zuen:
>=20
> John Wiegley <jwiegley@gmail.com> writes:
>=20
>> We're moving toward a future where Emacs.git will represent "core
>> Emacs", and only contain what core needs (plus a few historical bits,
>> I'm sure). There should be no argument for keeping a project in core
>> just to gain auxiliary benefits.
>=20
> I'm massively unenthusiastic about this future.  Things in ELPA has to
> be backwards-and-forwards compatible with a wide Emacs version range,

This seems like a technical limitation of ELPA=CA=BCs current implementatio=
n,
rather than a conceptual impossibility.  If ELPA made available (on the
server for downloading, and in the client for installing) old versions
of packages, then users could always be offered the latest compatible
version, but not later incompatible ones.

Developers would have to be a little more diligent about declaring their
packages=CA=BC dependencies on emacs major versions (or on other packages, =
if
they depend on parts of core that have migrated to ELPA), but this would
be a small hurdle.

Aaron

PS Speaking of dependency management, I=CA=BCd be more worried that this ki=
nd
of approach will accelerate the advent of dependency hell with ELPA
packages...but I think all package repos have to confront that problem
eventually.  So I=CA=BCd file that thought under =E2=80=9Cinevitable growin=
g pains=E2=80=9D
rather than =E2=80=9Carguments against=E2=80=9D.

--=20
Aaron Ecay