From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA package for CC-mode Date: Tue, 21 Aug 2018 16:20:43 +0000 Message-ID: <20180821162043.GA3946@ACM> References: <20180819204918.GA3934@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1534868855 571 195.159.176.226 (21 Aug 2018 16:27:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Aug 2018 16:27:35 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 21 18:27:30 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fs9VC-0008Tu-Me for ged-emacs-devel@m.gmane.org; Tue, 21 Aug 2018 18:27:30 +0200 Original-Received: from localhost ([::1]:54776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fs9XJ-00043h-6U for ged-emacs-devel@m.gmane.org; Tue, 21 Aug 2018 12:29:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fs9W7-00040m-Dn for emacs-devel@gnu.org; Tue, 21 Aug 2018 12:28:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fs9Vx-0004BN-1X for emacs-devel@gnu.org; Tue, 21 Aug 2018 12:28:23 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:38607 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fs9Vr-00044Q-4H for emacs-devel@gnu.org; Tue, 21 Aug 2018 12:28:13 -0400 Original-Received: (qmail 92247 invoked by uid 3782); 21 Aug 2018 16:28:05 -0000 Original-Received: from acm.muc.de (p5B1465F2.dip0.t-ipconnect.de [91.20.101.242]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 21 Aug 2018 18:28:04 +0200 Original-Received: (qmail 3952 invoked by uid 1000); 21 Aug 2018 16:20:43 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228789 Archived-At: 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).