From: tftorrey@tftorrey.com (T.F. Torrey)
To: Aaron Ecay <aaronecay@gmail.com>
Cc: now@disu.se, emacs-orgmode@gnu.org
Subject: Re: Bleeding edge in elpa
Date: Sun, 08 Mar 2015 11:09:46 -0700 [thread overview]
Message-ID: <877furuzrp.fsf@jack.tftorrey.com> (raw)
In-Reply-To: <87ioebmvex.fsf@gmail.com> (message from Aaron Ecay on Sun, 08 Mar 2015 11:17:19 -0300)
A major benefit of an ELPA version of the "bleeding edge" version of
Org is that it enables those of us who run Emacs and Org on machines
where we can not install git (or just do not want to) to have the latest
version of Org nonetheless.
In a real-world situation, I want to collaborate on Org files with my
wife and parents, and I want to use the current best version of Org
(which has significant improvements to #+INCLUDE that I use), but I do
not want to try to install git on their Windows machines, and I do not
want to scare them off by introducing the world of Git in addition to
Emacs. And it's not limited to #+INCLUDE. I've been using Org for many
years, and no matter how good a release of Org has been, the version in
maint has followed right behind with new killer features. Having that
version in Elpa makes it easier for me to share the awesome.
Aaron Ecay <aaronecay@gmail.com> writes:
> IMO this is a bad idea. The bleeding edge version is expected to be
> somewhat unstable, and exposing it via ELPA will lead to foot-shooting
> incidents.
I understand this concern in principle, but it is difficult for me to
imagine how it would be validated in actual usage.
Serious Org users are already forced to install and run git to use the
master version, and whatever the dangers, the practice is almost
completely without problems. A "bleeding edge" ELPA would merely make
that simpler.
I regularly use both the git master version of Org and the ELPA version
of Org, and I do extensive elisp coding that interacts with both, and I
do not remember a problem that could be described as "foot-shooting".
Any significant problems in a bleeding edge version would be resolved
the same way they are in the master version of git, only with the
solution packaged, delivered, and installed by the next day, except
automatically.
It is easy to imagine someone else unofficially packaging the bleeding
edge version and making it available via ELPA, and hard to imagine that
resulting in significant problems. Melpa is loaded with bleeding edge
versions, but the problems I hear or see from it are very rare.
Also, as noted before, if someone is unhappy with the "bleeding edge"
version, switching back would be easy.
> On the other hand, it would be nice to have more regular releases from
> master to maint. AFAIK the last one was a year and a half ago (Org
> 8.2). However, this has traditionally required a lot of effort from
> Bastien and others, so it’s not a simple case of “wishing will make it
> so”.
Very true, and no doubt there are benefits to having a "stable" version
available.
However, not providing the "bleeding edge" version on ELPA is not
without cost. The mailing list is littered with responses from Nicolas
saying "that problem has been fixed in the master version ...."
One last thought: I think it would be better to name the versions
"stable" and "unstable", to match the meanings established by Debian.
All the best,
Terry
--
T.F. Torrey
next prev parent reply other threads:[~2015-03-08 19:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull
2015-03-07 14:47 ` Xavier Maillard
2015-03-07 16:09 ` Nikolai Weibull
2015-03-08 5:48 ` Xavier Maillard
2015-03-09 9:08 ` Sebastien Vauban
2015-03-09 16:24 ` T.F. Torrey
2015-03-07 15:40 ` Grant Rettke
2015-03-07 21:44 ` T.F. Torrey
2015-03-08 1:32 ` Nicolas Girard
2015-03-08 14:17 ` Aaron Ecay
2015-03-08 17:24 ` Nikolai Weibull
2015-03-08 17:59 ` Achim Gratz
2015-03-08 18:34 ` Nikolai Weibull
2015-03-08 18:59 ` Rasmus
2015-03-09 6:48 ` T.F. Torrey
2015-03-10 1:57 ` Aaron Ecay
2015-03-10 21:30 ` T.F. Torrey
2015-03-11 2:51 ` Aaron Ecay
2015-03-11 19:18 ` T.F. Torrey
2015-03-11 19:59 ` Nick Dokos
2015-03-09 7:53 ` T.F. Torrey
2015-03-09 18:24 ` Achim Gratz
2015-03-09 19:21 ` T.F. Torrey
2015-03-10 11:01 ` Alexis
2015-03-10 15:21 ` Grant Rettke
2015-03-08 18:09 ` T.F. Torrey [this message]
2015-03-08 19:57 ` Rasmus
2015-03-08 20:20 ` Achim Gratz
2015-03-08 20:27 ` Rasmus
2015-03-08 20:36 ` Achim Gratz
2015-03-09 8:13 ` T.F. Torrey
2015-03-09 7:31 ` T.F. Torrey
2015-03-10 2:01 ` Richard Y. Kim
2015-03-10 6:29 ` Achim Gratz
2015-03-10 21:21 ` T.F. Torrey
2015-03-10 20:20 ` T.F. Torrey
2015-08-05 0:00 ` Bastien Guerry
2015-03-10 10:51 ` Steinar Bang
2015-03-10 17:11 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877furuzrp.fsf@jack.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=now@disu.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).