Re: Updating the "ELPA Protocol"

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I think we'd need more details and concrete examples to judge how best
>>> handle such renamings.  The problem I see is that in Emacs, names are
>>> very visible: the package name almost inevitably affect the ELisp
>>> files's names, which themselves affect the functions and vars defined
>>> therein.
>>>
>>> For that reason handling the renaming only in ELPA is rarely sufficient.
>>> And also for that reason, renamings are rare.
>>
>> From what I know this happens from time to time on MELPA.  The changes
>> usually have to be backwards-compatible or the renames must be trivial
>> (a change like "foo" -> "foo-mode" or vice versa).
>
> Interesting.  It would be great to have a (more or less exhaustive) list
> of renamings that took place in MELPA.

This is not really exhaustive, but a good starting point:

https://github.com/melpa/melpa/search?o=desc&q=rename&s=committer-date&type=commits

There are 234 commits with the word "rename".  Some are unrelated
renames because MELPA has a single repository for admin scripts and
specs, but most appear to be real package renames ("string-edit" ->
"string-edit-at-point", "farmhouse-theme" -> "farmhouse-themes",
"goldendict" -> "external-dict").

>> True, but I can imagine it causing confusion, when you find the actually
>> selected package being empty and the real package listed as a "mere"
>> dependency.
>
> I don't find it particularly confusing in Debian, because the new empty
> package usually describes itself fairly clearly as some kind of
> "transition package" where it say gives instructions on how to go about
> it (that you can remove it, etc..).

Hmm, I think I agree if we ensure that the transition package has a
clear description that would indicate it is a replacement.