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: Wed, 26 Oct 2022 11:05:14 +0300 Message-ID: <46afc709-7387-4af4-bd1b-9ec0f32e8d07@app.fastmail.com> References: <87o7u4p2t4.fsf@posteo.net> <5340a07b-a9bb-41a1-add2-4c0fe3f66e8c@app.fastmail.com> <87wn8nrt9q.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=c7652fd703e94099bdbff544711b67a3 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40015"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad Cc: "Emacs Devel" To: "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 26 10:06:56 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 1onbR7-000A6U-U7 for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Oct 2022 10:06:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onbQ1-0005bq-Ov; Wed, 26 Oct 2022 04:05:46 -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 1onbPy-0005Nx-B3 for emacs-devel@gnu.org; Wed, 26 Oct 2022 04:05:42 -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 1onbPt-0008C5-Ao for emacs-devel@gnu.org; Wed, 26 Oct 2022 04:05:39 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 99BCF5C0117; Wed, 26 Oct 2022 04:05:34 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 26 Oct 2022 04:05:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :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=1666771534; x=1666857934; bh=l0rVyrPE4K WrCgDFNrkXvYIpNcKPXZppEKF8g2iI66I=; b=rEylGKhElTDaVMUPwhKO+yCo5V 87KO4HHKVHMhzjYcTYcOYnf0ox5gXBsGGPGdMaTPRRX1K1ITAfPi8l2U7G/V7cbu 6snAU89r9VBOZHDW+CCMzGSxDzrjiZvb/XsYThZzkmcLfNCx4gIKcx+rGZk5yEze dhCisuHGaAI2s1tNRVFywAU33v1oZcpYvkrWFTMVHp8CFppc7BWOq7bLFvuSbt7I 7czXj+CYnMrLXgq4Z/CEvPC70MQJqa/NcRrvufY+U/aEbeO+T6mUZhYJ5cox2aiI LI7HqbpWJeehnKPr0hQMXWNGcs+Lp8LC+3WMa+yDkVW4yGgddr7NscQOsL7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1666771534; x=1666857934; bh=l0rVyrPE4KWrCgDFNrkXvYIpNcKP XZppEKF8g2iI66I=; b=dv6rClazfFMs6e57+d5DRPC0cCjV05aL94swaNMRH/YE gtLXV4NYGC9tALdiP8UPpS7tphKRs8z6TkZPfRHX+9oTxMIlXT80XScNRpd8oH3E U0yGJIWQ6sp98br7rBWV/JbXoD2G+daCgHtKWQdoQokH4ZgnmSKHSyq9rZ+RFh8h kkDm79cav/IUu3DaPOjnJqzq7YtW50UAIJreSNEdv3iPciwrFVZnETM3ZBWVW0cF cXq3p+95W8lC2rwshx7reOXDNWR5MftfesX8mVnA4ZM4V+H2dK5K8U6a4k57XCQ5 22C/vorcgXPUoPsXQRnLbiM/ZLxdd0PAneOmkqY/4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrtddugdduvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfueho iihhihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvh eqnecuggftrfgrthhtvghrnhepueelueeuieekgeeludefgeeufedttefffffhgedtleek tdduueekudeuveehieevnecuffhomhgrihhnpehmvghlphgrrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoiihhihgurghrsegs rghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56DBC2D40071; Wed, 26 Oct 2022 04:05:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <87wn8nrt9q.fsf@posteo.net> 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.001, RCVD_IN_MSPIKE_WL=0.001, 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:298522 Archived-At: --c7652fd703e94099bdbff544711b67a3 Content-Type: text/plain To be clear - I'm not arguing against the inclusion of this. :-) Assuming the package maintainers know what they are doing, that'd be perfectly fine by me. > Not quite, the time stamp is appended to the regular version number. Well, normally there's no "regular version" when you're doing rolling releases. If there is - those would not be rolling releases, but snapshots between regular releases. I know that MELPA preserves the original version, but I think that doesn't make sense for a real rolling release. On Wed, Oct 26, 2022, at 9:30 AM, Philip Kaludercic wrote: > "Bozhidar Batsov" writes: > > > Instead of setting version numbers manually (e.g. 0.1, 0.2) upon > > release time, with rolling releases every change (commit) pushed > > upstream results automatically in a new release and a version bump, > > with the version being a timestamp. > > Not quite, the time stamp is appended to the regular version number. > > > E.g. if I push 3 commits one day > > with some time between them this will result in 3 releases. I think > > it's a great approach for snapshot (devel) repos, but I'm not so sure > > about "stable" repos, as it kinda of implies that the author will > > never have their project in an inconsistent state (e.g. halfway > > towards a new feature). > > Right, so it would only be used whenever a package author prefers that > method of development. > > > This approach was made popular by https://melpa.org/ > > > > On Tue, Oct 25, 2022, at 11:14 PM, Richard Stallman wrote: > >> [[[ To any NSA and FBI agents reading my email: please consider ]]] > >> [[[ whether defending the US Constitution against all enemies, ]]] > >> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >> > >> > I have heard from people who prefer a rolling release model for their > >> > packages, > >> > >> Can you explain what that means, concretely? How is t different from > >> what we do now? > > It is currently necessary to bump the version tag in the package header > to indicate that a release is to be made. If a package specification > has a non-nil :rolling-release tag, then this is done whenever the > repository is synchronised. > > >> 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. > >> > >> Is this something we would _want_ to do? What would its implications > >> be for Emacs? > > It wouldn't affect Emacs, just packages that request this kind of > release management. > > >> We might decide to support their style of release, or decide not to > >> include their packages in NonGNU ELPA, or we might come up with > >> another solution. I don't know what's best. But I'm sure we should > >> think about that before we decide. > > If the only issue a package has is that it is developed using a "rolling > release" model, it would be nonsensical for us to not accommodate the > request and reject a (perhaps popular) package on that ground. > --c7652fd703e94099bdbff544711b67a3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
To be clear - I= 'm not arguing against the inclusion of this. :-) Assuming the package m= aintainers know what they are doing, that'd be perfectly fine by me.

Not quite, the time= stamp is appended to the regular version number.
=

Well, normally there's no "regular version" when you= 're doing rolling releases. If there is - those would not be rolling rel= eases, but snapshots between regular releases. I know that MELPA preserv= es the original version, but I think that doesn't make sense for a real = rolling release.

On Wed, Oct 26, 2022, at = 9:30 AM, Philip Kaludercic wrote:
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Instead of setting version numbers manually (e.g. 0.1, 0.2) upon=
> release time, with rolling releases every change (co= mmit) pushed
> upstream results automatically in a new = release and a version bump,
> with the version being a = timestamp.  

Not quite, the time = stamp is appended to the regular version number.

>          &n= bsp;           &n= bsp;           &n= bsp;   E.g. if I push 3 commits one day
> wit= h some time between them this will result in 3 releases. I think
> it's a great approach for snapshot (devel) repos, but I'm no= t so sure
> about "stable" repos, as it kinda of implie= s that the author will
> never have their project in an= inconsistent state (e.g. halfway
> towards a new featu= re).

Right, so it would only be used whenev= er a package author prefers that
method of development.

> This approach was made popular by <= a href=3D"https://melpa.org/">https://melpa.org/ 
>
> On Tue, Oct 25, 2022, at 11:14 PM, Richard Stal= lman wrote:
>> [[[ To any NSA and FBI agents reading= my email: please consider    ]]]
>> = [[[ whether defending the US Constitution against all enemies, &nbs= p;   ]]]
>> [[[ foreign or domestic, requi= res you to follow Snowden's example. ]]]
>> 
>>   > I have heard from people who prefe= r a rolling release model for their
>>   &= gt; packages,
>> 
>> Can yo= u explain what that means, concretely?  How is t different from
=
>> what we do now?

It is c= urrently necessary to bump the version tag in the package header
to indicate that a release is to be made.  If a package spec= ification
has a non-nil :rolling-release tag, then this is= done whenever the
repository is synchronised.

>>       &nbs= p;       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.
>= ;> 
>> Is this something we would _want_ to = do?  What would its implications
>> be for Emac= s?

It wouldn't affect Emacs, just packages = that request this kind of
release management.

>> We might decide to support their style of rele= ase, or decide not to
>> include their packages in N= onGNU ELPA, or we might come up with
>> another solu= tion.  I don't know what's best.  But I'm sure we should
>> think about that before we decide.

<= /div>
If the only issue a package has is that it is developed using = a "rolling
release" model, it would be nonsensical for us = to not accommodate the
request and reject a (perhaps popul= ar) package on that ground.

--c7652fd703e94099bdbff544711b67a3--