[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU ELPA package for CC-mode
From: |
Alan Mackenzie |
Subject: |
Re: GNU ELPA package for CC-mode |
Date: |
Tue, 21 Aug 2018 16:20:43 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Stefan.
On Sun, Aug 19, 2018 at 19:45:52 -0400, Stefan Monnier wrote:
[ .... ]
> 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.
I'm highly unlikely to introduce backward incompatibilities with Emacs
26. Somebody else using master as a development platform is more likely
to do so. But perhaps, as you say, this isn't really such a big issue.
> >> 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.
Ah. So it's metadata written into a source file. I'm against this.
Would it not be possible to store the version number elsewhere?
Metadata in ordinary files is ugly and causes problems. A significant
one being that VCS logs get polluted by updates of metadata, making it
unpleasant, or even difficult, to use a log display.
This "Version:" header certainly has no place in master, though I can
see an argument being made for it being included in an ELPA version of
CC Mode.
> > 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.
"Changes" is a verb with an agent. Under what scenario do you envisage
this version number being changed? Automatically upon a CC Mode commit
to master is what I thought you had in mind. Are you suggesting doing
this by hand when it takes somebody's fancy?
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- GNU ELPA package for CC-mode, Stefan Monnier, 2018/08/19
- Re: GNU ELPA package for CC-mode,
Alan Mackenzie <=
- Re: GNU ELPA package for CC-mode, Stefan Monnier, 2018/08/23
- Re: GNU ELPA package for CC-mode, Alan Mackenzie, 2018/08/23
- Re: GNU ELPA package for CC-mode, Stefan Monnier, 2018/08/23
- Re: GNU ELPA package for CC-mode, Eli Zaretskii, 2018/08/24
- Re: GNU ELPA package for CC-mode, Michael Albinus, 2018/08/24
- Re: GNU ELPA package for CC-mode, Stefan Monnier, 2018/08/24
- Tramp as ELPA package (was: GNU ELPA package for CC-mode), Michael Albinus, 2018/08/25
- Re: Tramp as ELPA package, Stefan Monnier, 2018/08/25
- Re: Tramp as ELPA package, Stefan Monnier, 2018/08/25
- Re: Tramp as ELPA package, Andreas Schwab, 2018/08/26