unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Allowing rolling release packages on ELPA
@ 2022-10-22 10:31 Philip Kaludercic
  2022-10-23  4:47 ` Protesilaos Stavrou
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Philip Kaludercic @ 2022-10-22 10:31 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread
* Re: Allowing rolling release packages on ELPA
@ 2022-10-26  5:58 Payas Relekar
  2022-10-26  8:07 ` Bozhidar Batsov
  0 siblings, 1 reply; 28+ messages in thread
From: Payas Relekar @ 2022-10-26  5:58 UTC (permalink / raw)
  To: Bozhidar Batsov; +Cc: Emacs Devel

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

--



^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2022-10-26 19:18 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-22 10:31 Allowing rolling release packages on ELPA Philip Kaludercic
2022-10-23  4:47 ` Protesilaos Stavrou
2022-10-23  8:43   ` Philip Kaludercic
2022-10-24  6:14   ` Bozhidar Batsov
2022-10-24  6:45     ` Jostein Kjønigsen
2022-10-24  8:07       ` Bozhidar Batsov
2022-10-24 14:06       ` Stefan Kangas
2022-10-26 19:18         ` Richard Stallman
2022-10-24 16:00       ` Philip Kaludercic
2022-10-24 16:39         ` Jostein Kjønigsen
2022-10-26 19:18           ` Richard Stallman
2022-10-24 19:27         ` Stefan Monnier
2022-10-24 15:58     ` Philip Kaludercic
2022-10-24 17:27     ` Stephen Leake
2022-10-24 19:40 ` Stefan Monnier
2022-10-26  6:32   ` Philip Kaludercic
2022-10-26 11:57     ` Stefan Monnier
2022-10-26 15:27       ` Philip Kaludercic
2022-10-26 18:31       ` Philip Kaludercic
2022-10-26 18:55         ` Stefan Monnier
2022-10-26 19:07           ` Philip Kaludercic
2022-10-25 20:14 ` Richard Stallman
2022-10-26  5:10   ` Bozhidar Batsov
2022-10-26  6:30     ` Philip Kaludercic
2022-10-26  8:05       ` Bozhidar Batsov
2022-10-26 19:18       ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2022-10-26  5:58 Payas Relekar
2022-10-26  8:07 ` Bozhidar Batsov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).