From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: org-export raises stringp nil error
Date: Fri, 08 Mar 2013 16:06:14 +0200
Message-ID: <83hakmyoix.fsf@gnu.org>
References: <87ip539io1.fsf@nautilus.nautilus>
	<ccwqtiq5dg.fsf@fencepost.gnu.org> <87zjye96ph.fsf@bzg.ath.cx>
	<jfd2va8yfy.fsf@fencepost.gnu.org> <87vc928kcm.fsf@bzg.ath.cx>
	<m1wqtipdhy.fsf@gmail.com> <83sj46z468.fsf@gnu.org>
	<m3zjye5k2s.fsf@chopper.vpn.verona.se>
	<87txomz1j7.fsf@yandex.ru> <83li9yyyul.fsf@gnu.org>
	<87a9qexhqc.fsf@yandex.ru>
Reply-To: Eli Zaretskii <eliz@gnu.org>
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
In-reply-to: <87a9qexhqc.fsf@yandex.ru>
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-bounces+ged-emacs-devel=m.gmane.org@gnu.org
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: lele@metapensiero.it, joakim@verona.se, emacs-devel@gnu.org, bzg@gnu.org, emacs-orgmode@gnu.org, sdl.web@gmail.com
List-Id: emacs-orgmode.gnu.org

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: lele@metapensiero.it,  joakim@verona.se,  emacs-devel@gnu.org,  bzg@gnu.org,  emacs-orgmode@gnu.org,  sdl.web@gmail.com
> Date: Fri, 08 Mar 2013 15:18:19 +0400
> 
> >> I like the idea of stripping big bundled packages (like org, gnus,
> >> cedet, maybe even tramp, if that's possible).
> >
> > That would certainly mean more problems for users to set them up with
> > a particular version of Emacs, because there's no longer a clear way
> > of getting the version of package X that correspond to Emacs version
> > N.M.
> 
> There won't be such correspondence.

And therein lies the problem.

> AFAIK, all 4 packages I mentioned above maintain backward compatible
> codebases, so it's not like they depend on the latest Emacs.

When I install a package, I usually want its latest *stable* version
that is compatible with the Emacs version I run.  As great as
compatibility stuff is, I trust testing more, as I need to do
something each day that doesn't involve debugging Emacs and my other
tools.

Also think about various package managers for GNU/Linux distros, which
need to specify on what version of Emacs package X depends.