[Top][All Lists]

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

Re: GNU ELPA package for CC-mode

From: Stefan Monnier
Subject: Re: GNU ELPA package for CC-mode
Date: Sun, 19 Aug 2018 19:45:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> I just tested the construction of a GNU ELPA package for CC-mode using
>> the :core thingy of elpa.git and everything looks good.
> Who's going to be testing this?  I've a slight suspicion that sometimes
> people add things to CC Mode that depend on things in master.  That would
> be subotimal for ELPA.

This has not proved to be a problem for other packages we handle this
way (e.g. soap-client, python.el, ...).
One of the reasons is that it's so cheap&quick to release a new version
that such problems are trivial to solve if/when they show up.

Also it's easier for contributors to discover that the package is
distributed via GNU ELPA than to try and search the web for some
indication that the package may be distributed separately somewhere (and
then try and figure out if that other distribution site is still related
to the code that's bundled with Emacs, ...), so I think contributors are
more aware of this issue for those :core GNU ELPA packages.

Finally, GNU ELPA packages are very rarely installed on Emacs<24 and
XEmacs, so backward incompatibilities are slightly less severe than what
you experience with your own distribution of CC-mode.

>> So I'm thinking of adding the patch below to elpa.git, which will cause
>> elpa.gnu.org to automatically construct a GNU ELPA package of CC-mode (from
>> the lisp/progmode/cc-*.el files in emacs.git).  If we do that, then
>> a new CC-mode ELPA package will be automatically constructed when the
>> "Version:" header of cc-mode.el is modified.
> This will need some new scheme for version numbers.
>> I just pushed to trunk a commit which added a "Version: 5.33.1" header
>> to cc-mode.el.
> What sort of "header"?

Search for "5.33" in the cc-mode.el of the master branch.

> No, 5.34 will be for the next standalone version (which hopefully won't
> be too far away).  I think the right thing to do will be to generate the
> "header" version number from the actual version number, and append some
> suffix characterising the ELPA version, which would be automatically
> incremented as commits are made to CC Mode.  Maybe.  Somehow.

The generation of the new package happens when the "Version:" header
changes, so I don't think we want this header to be auto-generated on
every commit.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]