[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU-devel and NonGNU-devel
From: |
Basil L. Contovounesios |
Subject: |
Re: GNU-devel and NonGNU-devel |
Date: |
Thu, 25 Feb 2021 02:19:47 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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.
Right, I was referring specifically to its default bleeding edge update
model.
>> 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?
Makes sense. Thanks for the info and for working on these,
--
Basil
- 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, 2021/02/21
- Re: GNU-devel and NonGNU-devel,
Basil L. Contovounesios <=
- 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
- Re: A different way to interactively pass options to commands, Jonas Bernoulli, 2021/02/23