From: Adam Porter <email@example.com> To: firstname.lastname@example.org Subject: Re: [ANN] org-ql 0.4 released Date: Wed, 22 Apr 2020 21:47:24 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CACv55yQu+52Xg=hF=d5LGhjm41sbQQ3Qa2WE3S5RYZZXrwJdZA@mail.gmail.com> David R <firstname.lastname@example.org> writes: > On Saturday, January 25, 2020, Adam Porter <email@example.com> 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [ANN] org-ql 0.4 released' \ /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
Code repositories for project(s) associated with this 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).