Re: GNU-devel and NonGNU-devel

[Basil L. Contovounesios]

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