[Top][All Lists]

[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: Thu, 23 Aug 2018 21:34:18 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Stefan.

On Thu, Aug 23, 2018 at 01:25:00 -0400, Stefan Monnier wrote:
> >> 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.

> Not sure I understand:

You don't understand the notion of the VCS logs becoming polluted?
Let's try again, then.  At the moment, if you do

    git log -- lisp/progmodes/cc-mode.el

, you get back details of changes to cc-mode.el which are all about the
development of CC Mode.  There's, however, one exception, your latest
change, which has nothing to do with the development of CC Mode.

What you're proposing may lead to these undesirable "exceptions", log
entries which have nothing to do with the development of CC Mode,
becoming common and swamping the substantive entries.  Were this to
happen, it would be unpleasant to scan a git log of cc-mode.el searching
for substantive changes amongst the obtrusive metadata change entries,
or it might possibly even be difficult.

There must surely be a better way of triggering ELPA releases which
doesn't involve this type of pollution.

> .... we currently have

>     (defconst c-version "5.33.1"

> in cc-defs.el.  In which way is this different?

In every possible way, bar the superficial.  c-version is an essential
part of CC Mode, and is THE version of CC Mode.  The proposed VERSION:
header is not a part of CC Mode, it is part of ELPA, recording the
number of the ELPA release only.

> > 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.

> The purpose of this "Version:" header is to document for package.el
> ....

Yes.  It's essentially part of package.el, not part of CC Mode or of

> .... which version of the cc-mode package is bundled with Emacs so
> that it ....

"It" being what?  Emacs?  package.el?

> .... can decide whether some other cc-mode ELPA package is more or
> less recent (and hence whether to activate that other package or not).

Sorry, I don't follow that bit.  Something's deciding something about
dates, and there are several CC Mode ELPA packages around.  Or

> So it very much belongs in `master`.

I can't follow your arguments, sorry.  Your conclusion doesn't appear to
follow from the arguments.  This proposed "Version:" header has no
purpose in master, only in package.el, isn't that right?

"Version:" in master would be pollution, which we want to avoid.  There
surely must be a better way.  How about putting it in a separate file,
called something like elpa-cc.el, or elpa-versions.el, or leaving it out
altogether?  Can ELPA releases be triggered by some mechanism which
doesn't involve changing a library's .el files?

> >> 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?

> Someone pushed a commit which changes that part of the file.

That wasn't the question I was attempting to ask; I wanted you to tell
me about the schedule for changing the version number, the criterion for
doing so, the frequency with which it will be done, things like that.

> > 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?

> Right: when you decide the code deserves a new GNU ELPA release.

It seems to make sense to make such a release on each CC Mode commit to
master.  I thought that was the idea - to keep the ELPA release
synchronised with master.  However, if we end up keeping this obtrusive
"Version:" in cc-mode.el, I would say do it on every tenth commit that
changes the substance of cc-mode.el, thus keeping the aforementioned
pollution within reasonable bounds.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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