From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: org-export raises stringp nil error Date: Fri, 08 Mar 2013 17:34:42 +0100 Message-ID: <87li9xu9y5.fsf@Rainer.invalid> References: <87ip539io1.fsf@nautilus.nautilus> <87zjye96ph.fsf@bzg.ath.cx> <87vc928kcm.fsf@bzg.ath.cx> <83sj46z468.fsf@gnu.org> <87txomz1j7.fsf@yandex.ru> <83li9yyyul.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: emacs-devel@gnu.org Cc: emacs-orgmode@gnu.org List-Id: emacs-orgmode.gnu.org Eli Zaretskii writes: > 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. As long as ELPA is in Git, that's absolutely no problem. The exact version of the package that's going into an Emacs release is tagged with that version. Emacs could even pull packages using these tags from ELPA if the user first decided to install the latest version and then wants to go back to the "built-in" package version. And release branches would be the way to handle code freezes. In any case, doing the built-in packages this way (or something similar) takes a lot of unecessary churn and merges out of the release process and I would think that would be a clear advantage to everyone involved. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada