[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU-devel and NonGNU-devel
From: |
Stefan Monnier |
Subject: |
Re: GNU-devel and NonGNU-devel |
Date: |
Sun, 21 Feb 2021 15:25:43 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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
- Re: A different way to interactively pass options to commands, (continued)
- Re: A different way to interactively pass options to commands, Óscar Fuentes, 2021/02/18
- Re: A different way to interactively pass options to commands, Stefan Monnier, 2021/02/18
- Development snapshots on GNU ELPA (was: A different way to interactively pass options to commands), Kévin Le Gouguec, 2021/02/18
- Re: A different way to interactively pass options to commands, Lars Ingebrigtsen, 2021/02/19
- Re: A different way to interactively pass options to commands, Stefan Monnier, 2021/02/19
- GNU-devel and NonGNU-devel (was: A different way to interactively pass options to commands), Basil L. Contovounesios, 2021/02/21
- Re: GNU-devel and NonGNU-devel,
Stefan Monnier <=
- Re: GNU-devel and NonGNU-devel, Basil L. Contovounesios, 2021/02/24
- Re: A different way to interactively pass options to commands, Jonas Bernoulli, 2021/02/19
- Re: A different way to interactively pass options to commands, Clemens, 2021/02/19
- Re: A different way to interactively pass options to commands, Jonas Bernoulli, 2021/02/21
- Re: A different way to interactively pass options to commands, T.V Raman, 2021/02/21
- Questions about transient (was: Re: A different way to interactively pass options to commands), Joost Kremers, 2021/02/22
- Re: Questions about transient (was: Re: A different way to interactively pass options to commands), Jonas Bernoulli, 2021/02/22
- Re: Questions about transient (was: Re: A different way to interactively pass options to commands), Joost Kremers, 2021/02/22
- RE: [External] : Questions about transient (was: Re: A different way to interactively pass options to commands), Drew Adams, 2021/02/22
- Re: A different way to interactively pass options to commands, Stephen Leake, 2021/02/23