Re: [ANN] org-ql 0.4 released

[Adam Porter <adam@alphapapa.net>]

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.