From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: [ANN] org-ql 0.4 released
Date: Wed, 22 Apr 2020 21:47:24 -0500 [thread overview]
Message-ID: <87eesehq9v.fsf@alphapapa.net> (raw)
In-Reply-To: CACv55yQu+52Xg=hF=d5LGhjm41sbQQ3Qa2WE3S5RYZZXrwJdZA@mail.gmail.com
David R <davidandrewrogers@gmail.com> writes:
> On Saturday, January 25, 2020, Adam Porter <adam@alphapapa.net> wrote:
>
>> I care about stability, not MELPA Stable. It's your choice to use MELPA
>> Stable, and you're free to upgrade or downgrade individual packages to
>> work around such occasional, temporary breakage caused by it--the pieces
>> are yours to keep. I'm sorry for any inconvenience, but your config is
>> up to you.
>
> It seems to me that this last statement ("Your config is up to you"),
> or perhaps the point of view that produces it, is not self-evident
> when applied to package versions. I think that in some way it's near
> the heart of the controversy.
>
> Maybe for me personally, my config being up to me (regarding package
> versions) is a disadvantage. I gratefully make use of a number of
> packages that I don't fully understand, and if I was required to study
> all of them until I was confident that I *did* fully understand them
> before installing, I'd just give up using Emacs at all.
That is not what I am suggesting.
I suggest that you:
1. Keep your Emacs config backed up, preferably with version control,
including all installed packges.
2. Upgrade packages deliberately, not "upgrade all upgradable
packages."
3. When you discover a problem caused by an upgrade, roll-back to a
known-good configuration until you have time to debug the problem.
This is what I recommend to all Emacs users. It does not require
understanding any packages' source code.
Elisp has no inter-package API. It's just a Lisp machine. Elisp
packages are just symbols that you load into your image. There is no
actual separation between packages' symbols. There are no versioned
APIs, no synchronized transitions.
Each user's configuation, image, set of installed packages, etc. is that
user's responsibility. In that sense, it's no different from a computer
system as a whole: you choose what software to install on it. If you
like or need a certain version of certain software, it's up to you to
ensure that you have a copy of it available. If you upgrade some
software and it doesn't work anymore with some other software version,
it's up to you to deal with it.
One of Emacs's chief strengths is user empowerment. That doesn't mean
that users need to know how everything works--not even the core Emacs
developers do. It means that you should know enough to maintain the
operability of the system, like you generally do for the rest of your
computer system.
The Emacs package "ecosystem" is not a "vendored" system. It's not like
Debian, with thousands of relatively curated packages maintained as a
middleman, expected to work together in a stable release. In Emacsland,
Each package (outside of Emacs and ELPA, and somewhat within ELPA as
well) is developed independently.
Nor should Emacs be treated like other software systems that are
live-updated whenever the developers hit the "push" button, with users
expecting the latest everything to work together all the time because
one party (ostensibly) takes responsibility for ensuring that.
Emacs gives the user the power. And with great power...well, you know.
Having said all that, the problems with MELPA Stable are, in a sense,
artificial, and they're orthogonal to these general issues. I can only
recommend, again, to not use it. If you're lucky, it will work fine.
When it doesn't, the solution will involve not using it. So you might
as well just skip it. If you want less-frequent package upgrades, just
don't upgrade your packages so frequently. Or use something like Quelpa
or Straight or Borg, where you can easily install the package versions
you want.
prev parent reply other threads:[~2020-04-23 2:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 1:03 [ANN] org-ql 0.4 released Adam Porter
2020-01-24 13:04 ` Michael Alan Dorman
2020-01-24 23:24 ` Adam Porter
2020-01-25 0:24 ` Tim Cross
2020-01-25 0:59 ` Adam Porter
2020-01-25 3:08 ` Michael Alan Dorman
2020-01-25 8:08 ` Adam Porter
2020-04-22 19:31 ` David R
2020-04-23 2:47 ` Adam Porter [this message]
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=87eesehq9v.fsf@alphapapa.net \
--to=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
/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).