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: Thu, 23 Aug 2018 21:34:18 +0000 Message-ID: <20180823213418.GA32596@ACM> References: <20180819204918.GA3934@ACM> <20180821162043.GA3946@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1535060743 4362 195.159.176.226 (23 Aug 2018 21:45:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Aug 2018 21:45:43 +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 Thu Aug 23 23:45:39 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 1fsxQB-00011x-7s for ged-emacs-devel@m.gmane.org; Thu, 23 Aug 2018 23:45:39 +0200 Original-Received: from localhost ([::1]:38873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsxSH-0001q7-JX for ged-emacs-devel@m.gmane.org; Thu, 23 Aug 2018 17:47:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsxS3-0001cb-5O for emacs-devel@gnu.org; Thu, 23 Aug 2018 17:47:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsxEB-0004Bh-3a for emacs-devel@gnu.org; Thu, 23 Aug 2018 17:33:18 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:64607 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fsxEA-0004Ae-O2 for emacs-devel@gnu.org; Thu, 23 Aug 2018 17:33:14 -0400 Original-Received: (qmail 59736 invoked by uid 3782); 23 Aug 2018 21:33:12 -0000 Original-Received: from acm.muc.de (p5B146787.dip0.t-ipconnect.de [91.20.103.135]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 23 Aug 2018 23:33:11 +0200 Original-Received: (qmail 332 invoked by uid 1000); 23 Aug 2018 21:34:18 -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:228855 Archived-At: 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 master. > .... 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 something. > 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).