[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Updating use-package, Version and Package-Version mess



Hi,

I'd like to ask for advises and suggestions concerning the use-package
package. There's a new upstream release, and I plan to update the
package in Debian.

As you may know it was already a kind of a mess, previously I had to
split use-package and bind-key, because these Emacs packages declared
different versions (say, 2.3 for use-package and 1.0 for bind-key; both
via Version declaration; which was also respected in MELPA), and Debian
supports only one version per source package (and it is not possiblt to
build several binary package with different versions from the same
source package).

Now it became a bit more complicated. So, there's 2.4 release, which
contains the following Emacs Lisp files (declared Version included, no
Package-Version declaration in the original source code):

bind-chord.el, 0.2
bind-key.el, 2.4
use-package-bind-key.el, 1.0
use-package-chords.el, 0.2
use-package-core.el, 2.4
use-package-delight.el, 1.0
use-package-diminish.el, 1.0
use-package-ensure-system-package.el, 0.2
use-package-ensure.el, 1.0
use-package-jump.el, 1.0
use-package-lint.el, 1.0
use-package.el, 2.4

Stable MELPA contains the following (declared Version and
Package-Version included):

bind-chord.el, 0.2, 2.4
bind-key.el, 2.4, 2.4

use-package.tar, 2.4 (no Package-Version declaration):
use-package-bind-key.el, 1.0
use-package-core.el, 2.4
use-package-delight.el, 1.0
use-package-diminish.el, 1.0
use-package-ensure.el, 1.0
use-package-jump.el, 1.0
use-package-lint.el, 1.0
use-package.el, 2.4

use-package-chords.el, 0.2, 2.4
use-package-ensure-system-package.el, 0.2, 2.4

So, sticking to stable MELPA version will not require splitting the
source code into several source packages. Should I patch Version (change
it everywhere to 2.4) or include Package-Version (as it is done in
MELPA)? The main motivation is to choose a plan which will not confuse
users running package-list-packages or some alternative (that is,
use-package and its related packages should not be marked as outdated or
something).

I'm open to all your advises and suggestions.

With regards,
Lev


Reply to: