Re: use-package.el -> Emacs core

[Stephen Leake <stephen_leake@stephe-leake.org>]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> What is the rationale for moving this to core instead of Gnu ELPA?

(My search of list-packages did not find `use-package' the first time,
so I did not realize it is already in Gnu ELPA).

> Well, it will be maintained by a core developer. :) 

Not a good reason; I maintain ada-mode in ELPA, because I want an
independent release cycle. But I still consider myself a minor Emacs
core developer.

> It would also be in the Emacs manual,

It can provide a .info file, which will be in the user's top level info
list. Is that not sufficient?

Hmm. It might be that other sections of the Emacs manual want to 
reference use-package. They can do so, as long as they clearly label it
as an ELPA package, so users will know how to find it. For example:

    If you use the (really cool) ELPA package @elparef{use-package},
    then you can do ...

I'm not clear exactly what "@elparef" should do, but it seems like a
good idea. Perhaps it should add the "ELPA package" text, so it is done
consistently. Can it add a clickable link to the package.el description
of the package?

> and blessed as an official method for declaring complex package
> configuration.

Ah. So you are asking us to agree that _this_ package is better than
other similar packages.

That's a reasonable request in general. But given the controversy around
CEDET, I think it needs to wait for emacs 25+, so we can establish a
process for such requests.

> Further, I wouldn't want it changing on users as ELPA updates. 
> Once a user downloads Emacs X.Y and reads the manual on how to write
> such configurations, the information should remain true until Emacs
> X.Z.

As the package maintainer, that's under your control; if you don't want
it to change, don't change it.

You are completely free to determine the release schedule for your ELPA
package. If you want it synced with Emacs releases, do that. There is a
small race condition window at the actual release, but I don't think
that's a significant problem. Proper use of Emacs version in the
dependency header should handle that.

If you want to work on it between releases, use a branch in ELPA git, or
a separate repository.


On the other hand, that means you can't release bug fixes, either. Nor
really cool but backward-compatible enhancements. I'd rather have a
package in ELPA, so I don't have to wait for the next Emacs release.

-- 
-- Stephe