From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org
Subject: Re: GNU-devel and NonGNU-devel
Date: Sun, 21 Feb 2021 15:25:43 -0500 [thread overview]
Message-ID: <jwvblcdtbr2.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87mtvxii7u.fsf_-_@tcd.ie> (Basil L. Contovounesios's message of "Sun, 21 Feb 2021 14:55:01 +0000")
> What are the exact differences in theory and practice between
> elpa.gnu.org/devel and elpa.gnu.org/packages, and
> elpa.nongnu.org/nongnu-devel and elpa.nongnu.org/nongnu?
The devel archives contain tarballs which reflect the current tip of the
Git branch (the one stored in `elpa.git` or `nongnu.git`, not
necessarily the same as the one upstream).
In contrast the non-devel archives only contain tarballs for those
commits where the `Version:` was changed.
> Are the devel archives intended as (possibly WIP) counterparts to MELPA?
It can be thought of as following the model of the non-stable part of
MELPA, but that doesn't make it MELPA to me at all since MELPA is
defined rather by the breadth of its coverage.
> Based on which criteria are new versions of devel packages released, and
> are they subject to :auto-sync in the same way as non-devel packages?
Sync'ing the elpa.git/nongnu.git branches with their upstream is
somewhat orthogonal to the devel-vs-release archives: the sync'ing is
always done between the upstream and the corresponding
elpa.git/nongnu.git branch. This sync'ing is done for all package in
nongnu.git and only for those tagged with :auto-sync in elpa.git.
Once a sync brings changes to a branch, that will always result in a new
tarball in the devel archive, but it will only result in a new package
in the release archive is the `Version:` changed.
> Can the two devel archives be used as drop-in replacements for the
> default package-archives?
If you're willing to use bleeding edge code, yes.
> What are the pros/cons of doing so from a user's perspective?
The risk of breakage?
Stefan
next prev parent reply other threads:[~2021-02-21 20:25 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 19:50 A different way to interactively pass options to commands Clemens
2021-02-17 20:07 ` Stefan Monnier
2021-02-17 20:20 ` Lars Ingebrigtsen
2021-02-17 22:05 ` Stefan Monnier
2021-02-19 5:41 ` Richard Stallman
2021-02-19 14:30 ` Stefan Monnier
2021-02-17 20:09 ` Lars Ingebrigtsen
2021-02-17 20:32 ` Clemens
2021-02-17 20:42 ` Lars Ingebrigtsen
2021-02-17 20:58 ` Clemens
2021-02-17 21:24 ` Clemens
2021-02-17 22:15 ` Stefan Monnier
2021-02-17 21:48 ` Óscar Fuentes
2021-02-17 22:23 ` Stefan Monnier
2021-02-17 22:47 ` Óscar Fuentes
2021-02-17 23:52 ` Clemens
2021-02-17 22:24 ` Lars Ingebrigtsen
2021-02-17 23:18 ` Óscar Fuentes
2021-02-18 10:09 ` Lars Ingebrigtsen
2021-02-18 1:16 ` Doug Davis
2021-02-18 10:03 ` Lars Ingebrigtsen
2021-02-18 10:39 ` Kévin Le Gouguec
2021-02-18 10:52 ` Lars Ingebrigtsen
2021-02-18 12:13 ` Dmitry Gutov
2021-02-18 17:45 ` Stefan Kangas
2021-02-18 17:55 ` Dmitry Gutov
2021-02-18 18:32 ` Stefan Kangas
2021-02-19 11:59 ` Lars Ingebrigtsen
2021-02-18 16:11 ` Óscar Fuentes
2021-02-18 15:40 ` Stefan Monnier
2021-02-18 16:28 ` Development snapshots on GNU ELPA (was: A different way to interactively pass options to commands) Kévin Le Gouguec
2021-02-19 12:01 ` A different way to interactively pass options to commands Lars Ingebrigtsen
2021-02-19 14:32 ` Stefan Monnier
2021-02-21 14:55 ` GNU-devel and NonGNU-devel (was: A different way to interactively pass options to commands) Basil L. Contovounesios
2021-02-21 20:25 ` Stefan Monnier [this message]
2021-02-25 2:19 ` GNU-devel and NonGNU-devel Basil L. Contovounesios
2021-02-19 15:44 ` A different way to interactively pass options to commands Jonas Bernoulli
2021-02-19 18:23 ` Clemens
2021-02-22 0:18 ` Jonas Bernoulli
2021-02-22 2:39 ` T.V Raman
2021-02-22 9:17 ` Questions about transient (was: Re: A different way to interactively pass options to commands) Joost Kremers
2021-02-22 15:08 ` Jonas Bernoulli
2021-02-22 21:06 ` Joost Kremers
2021-02-22 16:25 ` [External] : " Drew Adams
2021-02-23 12:15 ` A different way to interactively pass options to commands Stephen Leake
2021-02-23 19:06 ` Jonas Bernoulli
2021-02-19 5:42 ` Richard Stallman
2021-02-19 6:32 ` Stefan Kangas
2021-02-21 10:28 ` Phil Sainty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvblcdtbr2.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).