From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gGD+L+sBoV7FUgAA0tVLHw (envelope-from ) for ; Thu, 23 Apr 2020 02:48:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id UAQhJvEBoV79JgAAB5/wlQ (envelope-from ) for ; Thu, 23 Apr 2020 02:48:17 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 056C394288E for ; Thu, 23 Apr 2020 02:48:17 +0000 (UTC) Received: from localhost ([::1]:32960 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRRuR-0008Dn-67 for larch@yhetil.org; Wed, 22 Apr 2020 22:48:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33810) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRRtt-0008Df-Uk for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 22:47:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRRtr-0000QY-Jy for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 22:47:41 -0400 Received: from ciao.gmane.io ([159.69.161.202]:47650) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRRtp-0000Jx-GI for emacs-orgmode@gnu.org; Wed, 22 Apr 2020 22:47:38 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jRRtm-0000Sz-02 for emacs-orgmode@gnu.org; Thu, 23 Apr 2020 04:47:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Adam Porter Subject: Re: [ANN] org-ql 0.4 released Date: Wed, 22 Apr 2020 21:47:24 -0500 Message-ID: <87eesehq9v.fsf@alphapapa.net> References: <87ftg5vf70.fsf@alphapapa.net> <87blqt2ego.fsf@jaunder.io> <87blqsv3om.fsf@alphapapa.net> <87k15g1bck.fsf@jaunder.io> <871rroufeo.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Received-SPF: pass client-ip=159.69.161.202; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/22 22:47:34 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Received-From: 159.69.161.202 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: -0.61 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [-0.61 / 13.00]; GENERIC_REPUTATION(0.00)[-0.56426042755546]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.22), country: US(-0.00), ip: 209.51.188.17(-0.56)]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[209.51.188.17:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_NEQ_ENVFROM(0.00)[adam@alphapapa.net,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; URIBL_BLOCKED(0.00)[alphapapa.net:email]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[alphapapa.net]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: Mpek+KlKAuxF David R writes: > On Saturday, January 25, 2020, Adam Porter 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.