From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Allowing rolling release packages on ELPA Date: Mon, 24 Oct 2022 07:06:18 -0700 Message-ID: References: <87o7u4p2t4.fsf@posteo.net> <874jvvm9hn.fsf@protesilaos.com> <7c2bdbbd-bd23-cda9-50d4-23c4702215df@secure.kjonigsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33881"; mail-complaints-to="usenet@ciao.gmane.io" To: jostein@kjonigsen.net, Bozhidar Batsov , Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 18:13:33 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1on04y-0008c7-Uy for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 18:13:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omy5w-0007Kd-0J; Mon, 24 Oct 2022 10:06:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omy5u-0007KG-8N for emacs-devel@gnu.org; Mon, 24 Oct 2022 10:06:22 -0400 Original-Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1omy5s-0002jw-Hl for emacs-devel@gnu.org; Mon, 24 Oct 2022 10:06:22 -0400 Original-Received: by mail-ot1-x32a.google.com with SMTP id cb2-20020a056830618200b00661b6e5dcd8so5939287otb.8 for ; Mon, 24 Oct 2022 07:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:mime-version :references:in-reply-to:from:from:to:cc:subject:date:message-id :reply-to; bh=8tQqKahCf1/mQN+gbQVUj/sX7pvw+U8G6tuCLeemI8k=; b=pj5q/Mp1mUHSgX1qPNHKeZwqq9+u4zIKvSsxySKGSUXiH25rH11Bhg4co7MDMD8BsN /eZ43CDDX+8jfkSA7Nu+T8D9z96eop/Gba9ESkoO0qYDJz7Y1nZhXnWAQojzuRoyBu1T +85NMBrtf0/1esC2Wa08DK8Mi0zppdKh24aaJpHiEEHWrPPtEa6SLYKwxskvLZRHTMsw cA1qRW9QqB3CPEgIF1HmHKiz6/fVKjB44ALw3NimPNebOZf64r65utDYvt9VExhpzEZb Zws8zUTPmb6jxgcTnkIqFYCF1tSCnv7L4XvtLJ+EG9DYDTFfupNePC5A/8EFmacDmXTJ mpTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:mime-version :references:in-reply-to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=8tQqKahCf1/mQN+gbQVUj/sX7pvw+U8G6tuCLeemI8k=; b=NIiyyp4BdXrtkLq8SNAzroSiatp3qnW+ny4kZsvvbYdiGzOPAGWX16IF45sxTo0aJR 1NfUCjNgj43i3Hh0+RZjP496uvfDqF2ZpFWnXwjFkmN1GVbgRrD1hQ9vH5Uo4a9pia8/ 8sSxE8tkhRiNDs0zPQz8lpJEkrPcNAiHBhFV84TIMEc1vG0M24EiyHAL+egLlqPqEGdK qyLjVkV8FhzVslgepyHCZr7ReT6Dr0xQqJYnJFxn13+V/Ip6vPGauQFlecTYdb5YPC5t ahMW6NnwLGOoW7dyhcA/miMz5SVJc/NydbK2aI+5Bo8bw1Sg+NavJ4V0s7xMS+9Sz0Zu n/dA== X-Gm-Message-State: ACrzQf3rWY2BF3iNyZ8f/VVudzyflOG0wUH/edlSwd3Qg1BJqGFOaZDh CriqY1kuKfa2eW7ZR8KV+sap36f9hgyjvaUeExU= X-Google-Smtp-Source: AMsMyM5kxY+pV4r1gjl+mhyBo5JEbG12FVbL7pizqmedEMHT4hDLff8UQGVJrpywZHhue5PkTiGeaW95KXqw19h4bE4= X-Received: by 2002:a9d:4003:0:b0:661:b434:7e95 with SMTP id m3-20020a9d4003000000b00661b4347e95mr16034301ote.224.1666620378949; Mon, 24 Oct 2022 07:06:18 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 Oct 2022 07:06:18 -0700 In-Reply-To: <7c2bdbbd-bd23-cda9-50d4-23c4702215df@secure.kjonigsen.net> X-Hashcash: 1:20:221024:jostein@kjonigsen.net::VCHLODgod6miDeTu:2XIV Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=stefankangas@gmail.com; helo=mail-ot1-x32a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298380 Archived-At: Jostein Kj=C3=B8nigsen writes: > On 24.10.2022 08:14, Bozhidar Batsov wrote: >> The patch seems fine to me, but I'm a bit skeptical about the whole >> rolling releases idea in general > > This is the default operation for MELPA, Yes, and that is unfortunate, in my opinion. It is fine as an option, but I don't think it is the best default. There are different schools of thought here, but this is my take: When I upgrade my packages, I want to get a known-good version, not whatever happens to have just landed on the master branch. I tried the other way for years (with daily updates, etc.), and I eventually reached the conclusion that I just don't have the time to deal with the breakage in any of the nearly 100 packages that I have installed. I'm happier when I can just get my work done. So in my experience, the argument that rolling releases "works well in practice" has sadly not turned out to be true. I also note that not making proper releases places an undue burden (and in the long run probably unsustainable) on GNU/Linux distributions that want to package and ship a known-good version for their stable release. For more about this issue, please see: https://github.com/melpa/melpa/issues/6656#issuecomment-584467891 For many packages, development is slow enough that the latest commit is also always the latest release. The right thing in those cases, in the case of (Non-)GNU ELPA, is to update the "Version" header on every commit. It is trivial to do so automatically, for example with an Emacs hook. So it is already the case that not much extra work should be needed for those package maintainers that strongly prefer a rolling release model. For these reasons, and others, I'm not convinced about the need for adding specific support for the rolling release model to (Non-)GNU ELPA, outside of the devel archives. At the very least, we should think very carefully about it. Perhaps we should give it a couple of years to see what kind of influence NonGNU ELPA will or will not have on the habits of ELisp package maintainers.