From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: [ANN] org-ql 0.4 released
Date: Fri, 24 Jan 2020 17:24:09 -0600 [thread overview]
Message-ID: <87blqsv3om.fsf@alphapapa.net> (raw)
In-Reply-To: 87blqt2ego.fsf@jaunder.io
Michael Alan Dorman <mdorman@jaunder.io> writes:
>> Hi friends,
>>
>> FYI, I've released org-ql 0.4. It includes many improvements since 0.3.
>>
>> https://github.com/alphapapa/org-ql
>
> It would be nice if you could do a stable release of org-super-agenda so
> that it could be installed from melpa-stable...
Comments like yours lead me to the conclusion that MELPA Stable needs to
be abolished. I have been a proponent of the idea of MELPA Stable, so I
don't say that lightly.
I'll assume that you don't know what the technical issues are and offer
an explanation. Briefly:
+ MELPA Stable is nothing like what one might assume it's intended to be
like, e.g. Debian Stable or Debian Testing. It provides none of the
benefits that Debian Stable and Testing provide.
+ MELPA Stable is, just like "regular" MELPA, a "rolling" collection of
packages developed without any coordination between maintainers.
+ The only difference is that MELPA Stable contains whatever versions of
packages that their maintainers have decided to tag with a version
number, rather than the latest commit to the master branch. These
versions are not necessarily better, more stable, more reliable, or
more trustworthy than the untagged versions which appear in "regular"
MELPA.
+ Due to the lack of coordination between dependencies and their APIs,
version conflicts and breakage are a regular occurrence. For example,
if package A depends on package B, and package B makes an API change
and tags a new MELPA Stable release, users of package A's MELPA Stable
version will see package A cease to work properly until package A, not
only commits a fix, but tags a new MELPA Stable version containing the
fix. Since packages A and B do not share the same development
schedule, it is likely that their tagged-version release schedules
will not synchronize well.
If you are familiar with Debian, imagine if any upstream changes were
automatically pushed to Testing despite any freeze that might be in
place. It would be virtually impossible to complete a freeze and make
a new stable release, and Testing and Stable would cease to be useful,
leaving only Unstable as a usable target. This is the situation
between "regular" MELPA and MELPA Stable.
For my packages, I tag stable versions for a few reasons:
+ To help users track changes in the changelog.
+ To help me separate new, possibly bug-introducing changes from
working, debugged code.
+ To help packagers in systems like Debian and Guix, who package stable
versions of some Elisp packages--and who, in so doing, take
responsibility for breakage.
Now, I sympathize with not wanting to be vulnerable to potential
breakage caused by the uncoordinated release of changes to packages on
"regular" MELPA. That is a real problem. But the solution is not to
use MELPA Stable. The solution is to take charge of what packages you
upgrade and when, rather than being at the mercy of whatever commits
happen to be in MELPA at the moment.
For myself, I commit the ~/.emacs.d/elpa directory to Git with the rest
of my config, and I upgrade packages intentionally. If breakage
happens, I can easily revert and deal with it later. Other users use
alternative package managers, like Borg or Straight or Quelpa, which
pull changes directly from Git repos and allow pinning to commits, tags,
etc.
So, for yourself, I can only recommend that you abandon MELPA Stable and
install packages by other means. If you don't have the time or
inclination to redo your whole config like that, then just use something
like Quelpa to install the current version of org-super-agenda directly.
It's a couple lines of use-package in your config, and you can upgrade
it manually from then on, e.g. with
<https://github.com/alphapapa/unpackaged.el#upgrade-a-quelpa-use-package-forms-package>.
As always, your Emacs config is up to you.
Now, I'm off to to the discussions on MELPA's tracker to add my vote to
abolish MELPA Stable, or to at least allow packages to opt-out of it.
next prev parent reply other threads:[~2020-01-24 23:24 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 [this message]
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
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=87blqsv3om.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).