From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: Allowing rolling release packages on ELPA Date: Mon, 24 Oct 2022 09:14:55 +0300 Message-ID: References: <87o7u4p2t4.fsf@posteo.net> <874jvvm9hn.fsf@protesilaos.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bf488a8710b84acbbd86d0196c848bff Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10996"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 08:34:29 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 1omr2a-0002an-Pq for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 08:34:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omqkp-0004hf-JN; Mon, 24 Oct 2022 02:16:07 -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 1omqk7-0004PC-RR for emacs-devel@gnu.org; Mon, 24 Oct 2022 02:15:32 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omqk5-00016n-JT for emacs-devel@gnu.org; Mon, 24 Oct 2022 02:15:23 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2F4165C00A6 for ; Mon, 24 Oct 2022 02:15:17 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Mon, 24 Oct 2022 02:15:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1666592117; x=1666678517; bh=ROuD++r2/+ Ol/M6s7o5dGxlFGTgnoGfltP4L4Tv71HI=; b=Bh6aF+e1OIOE4d0cuuGZQb1Wgg ljyXMjd2GaKkDRvShNU0PmWJL+ygnwNEepHOVDlETPYM8I6Q5o0QuVp58yNxOt0V MRmfSgNRZjzR2tSojZ/CktsjL32ot5MdLS328qy8msPT04VYTsZ5cm6yqjmIW6hF 5lt728mYI4SPq1RdFPZdk9rxOvljmKFGHsW+7LPq5cqYmt0YVkMUkncadrpDQiTy jrEYryMn0tjXnb0Uu0DgLdc1vaQB922oyYNhpjUum6zv05umnWUZ7QI1CcTTDX2g YHUQKZBH0bAl9mMiNPy+efwbLuvzgrFwaMAlMaYpyBeSFUTlh2sCdp/fCsqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666592117; x=1666678517; bh=ROuD++r2/+Ol/M6s7o5dGxlFGTgn oGfltP4L4Tv71HI=; b=jNgLjbWI/OScJsmVjJ0er3wGvPBnwHf1bNjB2oT+P5Oi 0NA47rHGijPGEF2zbooR9rV+vkdunTdWPRA/a/ZCNVkB6076+YZyKpdW19bPXrL8 FXJH5gNLjbY5e/daIwOj0r/bh/scKMHFfINGvoGKsv0iYORwgr8xTmvDUw6eWXN+ yEA7SKbkuYRqRSBYyPH4lm+6sqp47KVmbBBFDD6UgTV04ZCuXovR8WDKg2DXssHo zuicty6nWtoPeSzLwOgP+7zrnlpiUTw9S+uhtAkWJ073YPLI5jw70HHjHBMOUdr8 9d7PL8fPUHByi0g9r8eywdbmefWFHQgoKnbUXFV6kg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgedtfedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfueho iihhihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvh eqnecuggftrfgrthhtvghrnhepiedvtddvueejtedukeehgfegudevveefveefhfevheej gfeuueekgfetkeejleeunecuffhomhgrihhnpehprhhothgvshhilhgrohhsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoiihh ihgurghrsegsrghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2AB82D4040A; Mon, 24 Oct 2022 02:15:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <874jvvm9hn.fsf@protesilaos.com> Received-SPF: pass client-ip=66.111.4.26; envelope-from=bozhidar@batsov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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:298341 Archived-At: --bf488a8710b84acbbd86d0196c848bff Content-Type: text/plain The patch seems fine to me, but I'm a bit skeptical about the whole rolling releases idea in general - e.g. should something like a change to the docs really result in a new release? How hard it is for people to actually update version timestamps themselves or to just stick to the *-devel repos if they don't want to cut releases? How much was the demand for something like this in general? I can't think of any major Emacs package that does rolling releases. On Sun, Oct 23, 2022, at 7:47 AM, Protesilaos Stavrou wrote: > > From: Philip Kaludercic > > Date: Sat, 22 Oct 2022 10:31:35 +0000 > > > > I have heard from people who prefer a rolling release model for their > > packages, and requested that their packages not be added for {Non,}GNU > > ELPA if they would have to update the version header manually, > > presumably on every commit. The following patch would enable ELPA > > devel-like versioning on ELPA, if enabled with a :rolling-release > > property. WDYT? > > Not a comment on the patch, but the idea behind it: I find the current > arrangement between GNU ELPA and GNU-devel ELPA to give me the best of > both worlds. Users who need rolling releases can opt in to the "devel" > version: this has the upside of explicitly acknowledging that the > package is not marked as "stable". > > The user can also arrange the 'package-archive-priorities' to choose > gnu-devel by default. And there is also 'package-pinned-packages' in > case they want a different archive for a given package. Example from my > init file where I prioritise regular GNU ELPA: > > (setq package-pinned-packages > '((cursory . "elpa-devel") > (denote . "elpa-devel") > (ef-themes . "elpa-devel") > (fontaine . "elpa-devel") > (lin . "elpa-devel") > (logos . "elpa-devel") > (pulsar . "elpa-devel") > (tmr . "elpa-devel"))) > > -- > Protesilaos Stavrou > https://protesilaos.com > > --bf488a8710b84acbbd86d0196c848bff Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The patch seems= fine to me, but I'm a bit skeptical about the whole rolling releases id= ea in general - e.g. should something like a change to the docs really r= esult in a new release? How hard it is for people to actually update ver= sion timestamps themselves or to just stick to the *-devel repos if they= don't want to cut releases?

How much was t= he demand for something like this in general? I can't think of any major= Emacs package that does rolling releases.

= On Sun, Oct 23, 2022, at 7:47 AM, Protesilaos Stavrou wrote:
> From: Philip Kalu= dercic <philipk@posteo.net&= gt;
> Date: Sat, 22 Oct 2022 10:31:35 +0000
>
> I have heard from people who prefer a rolling= release model for their
> packages, and requested that= their packages not be added for {Non,}GNU
> ELPA if th= ey would have to update the version header manually,
> = presumably on every commit.  The following patch would enable ELPA<= br>
> devel-like versioning on ELPA, if enabled with a :rol= ling-release
> property.  WDYT?

=
Not a comment on the patch, but the idea behind it: I find th= e current
arrangement between GNU ELPA and GNU-devel ELPA = to give me the best of
both worlds.  Users who need r= olling releases can opt in to the "devel"
version: this ha= s the upside of explicitly acknowledging that the
package = is not marked as "stable".

The user can als= o arrange the 'package-archive-priorities' to choose
gnu-d= evel by default.  And there is also 'package-pinned-packages' in
case they want a different archive for a given package. Exam= ple from my
init file where I prioritise regular GNU ELPA:=

    (setq package-pinned-pa= ckages
        &nb= sp; '((cursory . "elpa-devel")
    &nb= sp;       (denote . "elpa-devel")
           = (ef-themes . "elpa-devel")
     =        (fontaine . "elpa-devel")
=
            = (lin . "elpa-devel")
      &= nbsp;     (logos . "elpa-devel")
 = ;           (pulsar . = "elpa-devel")
       &n= bsp;    (tmr . "elpa-devel")))

-- 
Protesilaos Stavrou



--bf488a8710b84acbbd86d0196c848bff--