Re: MELPA version numbers

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Indeed, I just discovered "package-pinned-packages", which I presume
> is what you are referring to.  In theory it's a nice feature, but I
> really dislike the current implementation.  I am actually a bit
> disappointed about the quick hack that was use to implement this
> feature: When reading the package archives, package.el appears to just
> ignore(!) all package versions which are pinned to another archive.

Right, I haven't upgraded the code to follow the new style (filter
late, rather than filter early) for package-pinned-packages.
Patch welcome.

> and API of package.el.  I manage my packages through Carton (, and
> Carton has to

Ah, well if Carton has to

>> No, it doesn't really solve the problem: most people wouldn't know when
>> MELPA's version is out of date.  How would you know to switch archive if
>> package.el doesn't tell you that there's a newer version in the
>> "gnu" archive?
> How exactly can that happen given that MELPA *always* builds VCS
> snapshots, with are *by definition* the most recent state of a
> package?

Steve asks similarly:
> Can that even happen, for longer than a MELPA build cycle?

Well, it can happen (and has happened, IIRC I saw it for csv-mode, tho
it seems to be fixed now) because MELPA gives you the latest revision of
the DVCS branch it point at, but that branch may be abandoned.

> Or, in other words, if a GNU ELPA package happens to be more recent
> than MELPA, that's a failure in MELPA,

That's right.


        Stefan