Allowing rolling release packages on ELPA

Allowing rolling release packages on ELPA

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]


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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-support-for-rolling-release-packages.patch --]
[-- Type: text/x-patch, Size: 2262 bytes --]

From e6c928873683c9f5147ee6cb1301047b47b3208f Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 16 Oct 2022 18:05:40 +0200
Subject: [PATCH] Add support for rolling-release packages

* README: Document :rolling-release
* elpa-admin.el (elpaa--get-release-revision): Respect
:rolling-release.
(elpaa--make-one-package): Respect :rolling-release.
---
 README        | 6 +++++-
 elpa-admin.el | 3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/README b/README
index 4ff305047a..2e8a9e1156 100644
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
 #+TITLE: ELPA-Admin README
-#+DATE: 2022-01-06
+#+DATE: 2022-10-16
 
 Copyright (C) 2010-2022 Free Software Foundation, Inc. \\
 See the end of the file for license conditions.
@@ -168,6 +168,10 @@ this ORIG-VERSION (or REMAPPED-VERSION if non-nil) to override
 the default heuristic which uses the last revision that modified the
 "Version:" header.
 
+** =:rolling-release FLAG=
+If FLAG is non-nil, a new package will be released for every new
+commit, instead of just when the "Version" header is incremented.
+
 * Configuration (elpa-config)
 
 The configuration file is a `lisp-data-mode` file containing
diff --git a/elpa-admin.el b/elpa-admin.el
index d8f84e7205..054c9bda86 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -194,6 +194,7 @@ commit which modified the \"Version:\" pseudo header."
               (not (member vers (car version-map))))
     (pop version-map))
   (or (nth 2 (car version-map))
+      (and (elpaa--spec-get pkg-spec :rolling-release) "HEAD")
       ;; When the mainfile is a symlink (e.g. for :core packages), run Git
       ;; in the directory that holds the actual file, otherwise Git won't
       ;; know what file we're talking about.
@@ -952,6 +953,8 @@ place the resulting tarball into the file named TARBALL-ONLY."
                        (lambda () (cdr last-rel)))
                   (elpaa--release-email pkg-spec metadata dir)))))))
          (t
+          (when (elpaa--spec-get pkg-spec :rolling-release)
+            (setq vers devel-vers))
           (let ((tarball (concat elpaa--release-subdir
                                  (format "%s-%s.tar" pkgname vers))))
             (when (elpaa--make-one-tarball
-- 
2.38.0


[-- Attachment #3: Type: text/plain, Size: 139 bytes --]


I guess a counter argument is that you can use `time-stamp' with a
adequate file local configuration, I can't really say which is better.

Re: Allowing rolling release packages on ELPA

[Protesilaos Stavrou]

> From: Philip Kaludercic <philipk@posteo.net>
> 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

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

Protesilaos Stavrou <info@protesilaos.com> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> 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".

For the record, I agree that stable by default is preferable.  But I
actually am not a fan of promoting the usage of the "devel" archives,
as not all package developers (like me) want to ensure that the current
state of the default branch is usable.  It has happened more than once
to me that I have pushed a few commits that haven't been properly tested
at the end of the day, so that I can fetch that state from whatever
device I would be working on later, and having people complain to me
that this or that is broken.

All this being said, this has nothing to do with the motivation behind
the patch.  An example where a package developer has a mentality
opposite to mine can be found here[0].  He claims that all commits are
stable and usable, so the requirement to bump the version tag manually
would be an unnecessary burden.

[0] https://github.com/greghendershott/racket-mode/issues/389

> 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")))

I don't understand the detour through ELPA-devel is necessary, if I
would suppose that you have the package sources available locally?

Re: Allowing rolling release packages on ELPA

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

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 <philipk@posteo.net>
> > 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
> 
> 

[-- Attachment #2: Type: text/html, Size: 3289 bytes --]

Re: Allowing rolling release packages on ELPA

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

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, which arguably has more popular 
packages than ELPA.

It works fine.

> should something like a change to the docs really result in a new release?

Yes. Unconditionally.

Every patch is probably a feature or a bug-fix to some aspect of the 
package. As a user, I want those as soon as they are available.

> 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?

As a package-developer, I may release patches weekly, but I update main 
versions maybe once every second year, if/when someone bothers me about it.

Not having to version things manually is a god-send.

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

All of them does, if they're on MELPA. That's what MELPA does.

--

Jostein


[-- Attachment #2: Type: text/html, Size: 2223 bytes --]

Re: Allowing rolling release packages on ELPA

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Well the argument about MELPA is a bit misplaced, as there's also MELPA Stable. I mean snapshots are not a bad idea if you know what you're doing (I'm using MELPA myself), but most packages still have "stable" releases. I can't think of a single package that I use that doesn't get tagged releases from time to time. 

I was also under the impression that there are already ELPA and NonGNU devel repositories that behave like MELPA, so I'm not sure what would we be solving then. 

> Every patch is probably a feature or a bug-fix to some aspect of the package. As a user, I want those as soon as they are
> available.

Often that's not the case - patches can be improvements to docs, build infrastructure, small steps towards some new features, etc. 

> Not having to version things manually is a god-send.

It saves a tiny bit of time for the maintainers and makes life a bit harder for the end users IMO. Anyways, perspective on this subject will always vary. For me updating a couple of version numbers in a package is an insignificant amount of work (and it's work that's trivial to automate). 

On Mon, Oct 24, 2022, at 9:45 AM, Jostein Kjønigsen wrote:
> 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, which arguably has more popular packages than ELPA.
> 
> It works fine.
> 
>> should something like a change to the docs really result in a new release?
> Yes. Unconditionally.
> 
> Every patch is probably a feature or a bug-fix to some aspect of the package. As a user, I want those as soon as they are available.
> 
>> 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?
> As a package-developer, I may release patches weekly, but I update main versions maybe once every second year, if/when someone bothers me about it.
> 
> Not having to version things manually is a god-send.
> 
>> 
>> How much was the demand for something like this in general? I can't think of any major Emacs package that does rolling releases.
> All of them does, if they're on MELPA. That's what MELPA does.
> 
> --
> 
> Jostein
> 

[-- Attachment #2: Type: text/html, Size: 3374 bytes --]

Re: Allowing rolling release packages on ELPA

[Stefan Kangas]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> 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.

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

(Btw, please don't forget to wide-reply when responding on the mailing
list.  I missed this message at first because gmane was not working
properly yesterday).

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> 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?

In principle I agree, but there are people who insist on it as I mention
in response to Protesilaos' message.  If every commit is a significant
change, then any time that ELPA synchronises the repository is the right
time to publish a new release.

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

I have been talking with a lot of maintainers over the last year or so
and there were certainly some that preferred rolling, perhaps not so
much because they are always working on new features, but rather because
the code was relatively stable that the only changes are bug fixes.

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> 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, which arguably has more
> popular packages than ELPA.

To my knowledge all of the major packages on MELPA are also available
via GNU or NonGNU ELPA, so I don't know if this is really an argument.

>> 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?
>
> As a package-developer, I may release patches weekly, but I update
> main versions maybe once every second year, if/when someone bothers me
> about it.
>
> Not having to version things manually is a god-send.

It really depends, I am certainly no recommending to enable this by
default.  The idea is just to accommodate people like you who prefer
this mode of publishing releases.

Re: Allowing rolling release packages on ELPA

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]


On Mon, Oct 24, 2022, at 18:00, Philip Kaludercic wrote:
> Jostein Kjønigsen <jostein@secure.kjonigsen.net> 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, which arguably has more
> > popular packages than ELPA.
> 
> To my knowledge all of the major packages on MELPA are also available
> via GNU or NonGNU ELPA, so I don't know if this is really an argument.
> 
> >> 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?
> >
> > As a package-developer, I may release patches weekly, but I update
> > main versions maybe once every second year, if/when someone bothers me
> > about it.
> >
> > Not having to version things manually is a god-send.
> 
> It really depends, I am certainly no recommending to enable this by
> default.  The idea is just to accommodate people like you who prefer
> this mode of publishing releases.
> 

I’m not arguing it should be the default, for everyone. 

I’m just supporting having rolling releases as a possibility. Lots of users and developers prefer it that way. 

In fact that’s how I (as a user) consume Emacs: git pull and build. I’m not waiting for official tagged versions. 

[-- Attachment #2: Type: text/html, Size: 2191 bytes --]

Re: Allowing rolling release packages on ELPA

[Stephen Leake]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> 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?

The devel repos are not enabled by default; part of the point of the
Gnu ELPA packages is that they "just work" out of the box.

If it's easy to support (as the patch suggests), and totally up to each
package maintainer to choose, then what is the downside of allowing it? 

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

Since Melpa allows this, I'm betting there are some there. Although we
could easily quibble over the meaning of "major" here; if a package has
more than one user, this sort of thing matters.

-- 
-- Stephe

Re: Allowing rolling release packages on ELPA

[Stefan Monnier]

>> This is the default operation for MELPA, which arguably has more
>> popular packages than ELPA.
> To my knowledge all of the major packages on MELPA are also available
> via GNU or NonGNU ELPA, so I don't know if this is really an argument.

For some packages (e.g. haml-mode and smartparens), we actually use the
`:version-map` hack to make releases, for lack of a `:version:` header.
So while it's not a common problem, it's real.


        Stefan

Re: Allowing rolling release packages on ELPA

[Stefan Monnier]

Hi Philip,

> presumably on every commit.  The following patch would enable ELPA
> devel-like versioning on ELPA, if enabled with a :rolling-release
> property.  WDYT?

[ I can imagine cases where we may need to explicitly set the "base version"
  from which the rolling-release version is computed, but we can cross
  this bridge when/if we get there.   ]

I would suggest to add a mention in the doc saying that this
is discouraged.
Also, it should say that it is not compatible with `:release-branch`
and we should signal an error if `:release-branch` is set.  Or maybe
make it a special value of `:release-branch` rather than a new keyword?

More importantly, it would be good to notice when that flag is out of
date, i.e. signal an error if the `Version:` has changed when that flag
is set.  Maybe simply require that flag to be set to a string (rather
than just `t`) which is the expected version specified in `Version:` and
then signal an error if they don't agree?


        Stefan

Re: Allowing rolling release packages on ELPA

[Richard Stallman]

[[[ 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?

              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?

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.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Allowing rolling release packages on ELPA

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

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.  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). 

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?
> 
>               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?
> 
> 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.
> 
> 
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
> 
> 
> 
> 

[-- Attachment #2: Type: text/html, Size: 2834 bytes --]

Re: Allowing rolling release packages on ELPA

[Payas Relekar]

I'd say this approach is quite feasible, there are even popular GNU/Linux
distributions out there who don't do big timely releases, but have
rolling package updates, one of them I've been using for years with zero
issues.

This generally relies upon development and deployment being supportive
of it.

Some developers prefer to do development in separate branches. Git makes
this cheap and easy to the point of being free. When features/bug fixes
are good enough they can be safely merged to master with little to no
effort. Emacs itself does this quite often for big features
(native-comp, pgtk, tree-sitter). This way master is almost guaranteed
to be 'green'.

IMO the status quo is a good default, but having an option of rolling
updates is good for developers that follow branched development.

"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 (commit) pushed upstream results
> automatically in a new release and a version bump, with the version being a
> timestamp. 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).
>
> 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?
>>
>>               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?
>>
>> 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.
>>
>>
>> --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisance of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-of-Famer (https://internethalloffame.org)
>>
>>
>>
>>

--

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

"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 (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.

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hi Philip,
>
>> presumably on every commit.  The following patch would enable ELPA
>> devel-like versioning on ELPA, if enabled with a :rolling-release
>> property.  WDYT?
>
> [ I can imagine cases where we may need to explicitly set the "base version"
>   from which the rolling-release version is computed, but we can cross
>   this bridge when/if we get there.   ]
>
> I would suggest to add a mention in the doc saying that this
> is discouraged.
> Also, it should say that it is not compatible with `:release-branch`
> and we should signal an error if `:release-branch` is set.  Or maybe
> make it a special value of `:release-branch` rather than a new keyword?

You are right, it should be explicitly discouraged.  Overloading
:release-branch seems to hacky IMO.

> More importantly, it would be good to notice when that flag is out of
> date, i.e. signal an error if the `Version:` has changed when that flag
> is set.  Maybe simply require that flag to be set to a string (rather
> than just `t`) which is the expected version specified in `Version:` and
> then signal an error if they don't agree?

Sure, that can be done but I don't see why?

Re: Allowing rolling release packages on ELPA

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

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" <bozhidar@batsov.dev> 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.
> 

[-- Attachment #2: Type: text/html, Size: 4762 bytes --]

Re: Allowing rolling release packages on ELPA

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]

To be clear - I'm arguing against rolling releases, just pointing out they require a bit
of due diligence on their maintainers part.  But if someone requested this explicitly I guess
we can assume they know what they are doing. 

On Wed, Oct 26, 2022, at 8:58 AM, Payas Relekar wrote:
> I'd say this approach is quite feasible, there are even popular GNU/Linux
> distributions out there who don't do big timely releases, but have
> rolling package updates, one of them I've been using for years with zero
> issues.
> 
> This generally relies upon development and deployment being supportive
> of it.
> 
> Some developers prefer to do development in separate branches. Git makes
> this cheap and easy to the point of being free. When features/bug fixes
> are good enough they can be safely merged to master with little to no
> effort. Emacs itself does this quite often for big features
> (native-comp, pgtk, tree-sitter). This way master is almost guaranteed
> to be 'green'.
> 
> IMO the status quo is a good default, but having an option of rolling
> updates is good for developers that follow branched development.
> 
> "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 (commit) pushed upstream results
> > automatically in a new release and a version bump, with the version being a
> > timestamp. 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).
> >
> > 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?
> >>
> >>               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?
> >>
> >> 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.
> >>
> >>
> >> --
> >> Dr Richard Stallman (https://stallman.org)
> >> Chief GNUisance of the GNU Project (https://gnu.org)
> >> Founder, Free Software Foundation (https://fsf.org)
> >> Internet Hall-of-Famer (https://internethalloffame.org)
> >>
> >>
> >>
> >>
> 
> --
> 

[-- Attachment #2: Type: text/html, Size: 4866 bytes --]

Re: Allowing rolling release packages on ELPA

[Stefan Monnier]

>> More importantly, it would be good to notice when that flag is out of
>> date, i.e. signal an error if the `Version:` has changed when that flag
>> is set.  Maybe simply require that flag to be set to a string (rather
>> than just `t`) which is the expected version specified in `Version:` and
>> then signal an error if they don't agree?
>
> Sure, that can be done but I don't see why?

Because more often than I'd like, upstream management changes without us
being made aware of them.  So especially for discouraged flags, we should
make extra sure that these flags are still desired.


        Stefan

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> More importantly, it would be good to notice when that flag is out of
>>> date, i.e. signal an error if the `Version:` has changed when that flag
>>> is set.  Maybe simply require that flag to be set to a string (rather
>>> than just `t`) which is the expected version specified in `Version:` and
>>> then signal an error if they don't agree?
>>
>> Sure, that can be done but I don't see why?
>
> Because more often than I'd like, upstream management changes without us
> being made aware of them.  So especially for discouraged flags, we should
> make extra sure that these flags are still desired.

I see.  Sure, I'll try and update the patch for that to work as well.

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> More importantly, it would be good to notice when that flag is out of
>>> date, i.e. signal an error if the `Version:` has changed when that flag
>>> is set.  Maybe simply require that flag to be set to a string (rather
>>> than just `t`) which is the expected version specified in `Version:` and
>>> then signal an error if they don't agree?
>>
>> Sure, that can be done but I don't see why?
>
> Because more often than I'd like, upstream management changes without us
> being made aware of them.  So especially for discouraged flags, we should
> make extra sure that these flags are still desired.

How does this look like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-support-for-rolling-release-packages.patch --]
[-- Type: text/x-patch, Size: 3335 bytes --]

From 6f746b919d3a377cf8ef0f9aa34ebbf9969b0188 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 16 Oct 2022 18:05:40 +0200
Subject: [PATCH] Add support for rolling-release packages

* README: Document :rolling-release
* elpa-admin.el (elpaa--get-release-revision): Respect
:rolling-release.
(elpaa--make-one-package): Respect :rolling-release.
---
 README        | 11 ++++++++++-
 elpa-admin.el | 10 +++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 4ff305047a..1c42f13cd7 100644
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
 #+TITLE: ELPA-Admin README
-#+DATE: 2022-01-06
+#+DATE: 2022-10-26
 
 Copyright (C) 2010-2022 Free Software Foundation, Inc. \\
 See the end of the file for license conditions.
@@ -168,6 +168,15 @@ this ORIG-VERSION (or REMAPPED-VERSION if non-nil) to override
 the default heuristic which uses the last revision that modified the
 "Version:" header.
 
+** =:rolling-release FLAG=
+If FLAG is non-nil, a new package will be released for every new
+commit, instead of just on incrementing the "Version" header.  FLAG
+can optionally be a string, in which case the package is only released
+if the version is equal to FLAG.
+
+Note that the usage of this option is discouraged.  Only use it if the
+package maintainer explicitly wishes to use a "rolling release" model.
+
 * Configuration (elpa-config)
 
 The configuration file is a `lisp-data-mode` file containing
diff --git a/elpa-admin.el b/elpa-admin.el
index a1eec9c448..7ed78430d6 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -194,6 +194,7 @@ commit which modified the \"Version:\" pseudo header."
               (not (member vers (car version-map))))
     (pop version-map))
   (or (nth 2 (car version-map))
+      (and (elpaa--spec-get pkg-spec :rolling-release) "HEAD")
       ;; When the mainfile is a symlink (e.g. for :core packages), run Git
       ;; in the directory that holds the actual file, otherwise Git won't
       ;; know what file we're talking about.
@@ -945,7 +946,8 @@ place the resulting tarball into the file named TARBALL-ONLY."
                                          dir pkg-spec
                                          `(nil ,devel-vers
                                                . ,(nthcdr 2 metadata))
-                                         nil tarball-only))))
+                                         nil tarball-only)))
+             (rolling-release (elpaa--spec-get pkg-spec :rolling-release)))
 
         ;; Try and build the latest release tarball.
         (cond
@@ -972,7 +974,13 @@ place the resulting tarball into the file named TARBALL-ONLY."
                        tarball dir pkg-spec metadata
                        (lambda () (cdr last-rel)))
                   (elpaa--release-email pkg-spec metadata dir)))))))
+         ((and (stringp rolling-release)
+               (not (version= rolling-release vers)))
+          (elpaa--message "Expected version %s, but got %s for package %s!"
+                          rolling-release vers  pkgname))
          (t
+          (when rolling-release
+            (setq vers devel-vers))
           (let ((tarball (concat elpaa--release-subdir
                                  (format "%s-%s.tar" pkgname vers))))
             (when (elpaa--make-one-tarball
-- 
2.38.0

Re: Allowing rolling release packages on ELPA

[Stefan Monnier]

> How does this look like:

LGTM, thanks.

[ We may want to refine this later, e.g. to avoid the resulting
  redundancy between GNU and GNU-devel, but I'm not sure yet what we'll
  want to do it about it, so let's see how it works first.  ]


        Stefan


> From 6f746b919d3a377cf8ef0f9aa34ebbf9969b0188 Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Sun, 16 Oct 2022 18:05:40 +0200
> Subject: [PATCH] Add support for rolling-release packages
>
> * README: Document :rolling-release
> * elpa-admin.el (elpaa--get-release-revision): Respect
> :rolling-release.
> (elpaa--make-one-package): Respect :rolling-release.
> ---
>  README        | 11 ++++++++++-
>  elpa-admin.el | 10 +++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/README b/README
> index 4ff305047a..1c42f13cd7 100644
> --- a/README
> +++ b/README
> @@ -1,5 +1,5 @@
>  #+TITLE: ELPA-Admin README
> -#+DATE: 2022-01-06
> +#+DATE: 2022-10-26
>  
>  Copyright (C) 2010-2022 Free Software Foundation, Inc. \\
>  See the end of the file for license conditions.
> @@ -168,6 +168,15 @@ this ORIG-VERSION (or REMAPPED-VERSION if non-nil) to override
>  the default heuristic which uses the last revision that modified the
>  "Version:" header.
>  
> +** =:rolling-release FLAG=
> +If FLAG is non-nil, a new package will be released for every new
> +commit, instead of just on incrementing the "Version" header.  FLAG
> +can optionally be a string, in which case the package is only released
> +if the version is equal to FLAG.
> +
> +Note that the usage of this option is discouraged.  Only use it if the
> +package maintainer explicitly wishes to use a "rolling release" model.
> +
>  * Configuration (elpa-config)
>  
>  The configuration file is a `lisp-data-mode` file containing
> diff --git a/elpa-admin.el b/elpa-admin.el
> index a1eec9c448..7ed78430d6 100644
> --- a/elpa-admin.el
> +++ b/elpa-admin.el
> @@ -194,6 +194,7 @@ commit which modified the \"Version:\" pseudo header."
>                (not (member vers (car version-map))))
>      (pop version-map))
>    (or (nth 2 (car version-map))
> +      (and (elpaa--spec-get pkg-spec :rolling-release) "HEAD")
>        ;; When the mainfile is a symlink (e.g. for :core packages), run Git
>        ;; in the directory that holds the actual file, otherwise Git won't
>        ;; know what file we're talking about.
> @@ -945,7 +946,8 @@ place the resulting tarball into the file named TARBALL-ONLY."
>                                           dir pkg-spec
>                                           `(nil ,devel-vers
>                                                 . ,(nthcdr 2 metadata))
> -                                         nil tarball-only))))
> +                                         nil tarball-only)))
> +             (rolling-release (elpaa--spec-get pkg-spec :rolling-release)))
>  
>          ;; Try and build the latest release tarball.
>          (cond
> @@ -972,7 +974,13 @@ place the resulting tarball into the file named TARBALL-ONLY."
>                         tarball dir pkg-spec metadata
>                         (lambda () (cdr last-rel)))
>                    (elpaa--release-email pkg-spec metadata dir)))))))
> +         ((and (stringp rolling-release)
> +               (not (version= rolling-release vers)))
> +          (elpaa--message "Expected version %s, but got %s for package %s!"
> +                          rolling-release vers  pkgname))
>           (t
> +          (when rolling-release
> +            (setq vers devel-vers))
>            (let ((tarball (concat elpaa--release-subdir
>                                   (format "%s-%s.tar" pkgname vers))))
>              (when (elpaa--make-one-tarball

Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> How does this look like:
>
> LGTM, thanks.

Great, pushed the change.

Re: Allowing rolling release packages on ELPA

[Richard Stallman]

[[[ 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. ]]]

  > In fact that’s how I (as a user) consume Emacs:

It is impossible to "consume" GNU Emacs.  We use it, but using it does
not consume it.  Even if you kill an Emacs process, the program Emacs
remains, ready to run again.

See https://gnu.org/philosophy/words-to-avoid.html#Consume.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Allowing rolling release packages on ELPA

[Richard Stallman]

[[[ 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. ]]]

  > 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.

Your whole message seems wise to me.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Allowing rolling release packages on ELPA

[Richard Stallman]

[[[ 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. ]]]

  > >> 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.

It may sometimes be good for us to accept such packages and call each
version a "release."  But we have another way to accept them: to
selectively copy some versions and call them "releases", while
omitting other versions.

I don't think either approach is inherently nonsensical.
We should not rule either one out arbitrarily.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)