From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA package for CC-mode Date: Thu, 23 Aug 2018 18:17:22 -0400 Message-ID: References: <20180819204918.GA3934@ACM> <20180821162043.GA3946@ACM> <20180823213418.GA32596@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535062617 21395 195.159.176.226 (23 Aug 2018 22:16:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Aug 2018 22:16:57 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 00:16:53 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 1fsxuP-0005Pw-1q for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 00:16:53 +0200 Original-Received: from localhost ([::1]:38972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsxwT-0002o2-MU for ged-emacs-devel@m.gmane.org; Thu, 23 Aug 2018 18:19:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsxv5-00026d-I6 for emacs-devel@gnu.org; Thu, 23 Aug 2018 18:17:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsxv2-0006Yj-Bw for emacs-devel@gnu.org; Thu, 23 Aug 2018 18:17:35 -0400 Original-Received: from [195.159.176.226] (port=56127 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fsxv2-0006Xb-47 for emacs-devel@gnu.org; Thu, 23 Aug 2018 18:17:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fsxss-0003n9-OK for emacs-devel@gnu.org; Fri, 24 Aug 2018 00:15:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 107 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:wQc3sZPG8jfWHMvw3qhULS2+XRI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:228856 Archived-At: > You don't understand the notion of the VCS logs becoming polluted? No, indeed, see below. > In every possible way, bar the superficial. c-version is an essential > part of CC Mode, Hardly: I removed it in my local Emacs and everything works just as well as before. > 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. The "Version:" header could just as well be THE version. So, I still don't see in which way they're fundamentally different. >> > 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. I don't think the version of a package can be considered to be "part of package.el". >> .... which version of the cc-mode package is bundled with Emacs so >> that it .... > "It" being what? Emacs? package.el? package.el or "Emacs via 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). >> So it very much belongs in `master`. > I can't follow your arguments, sorry. Here's the scenario: - Scene 1: Georges is happily using Emacs-25.4 when he notices that he'd like the support for newer C++ language features present in the newer version of CC-mode, so he installs a newer CC-mode package locally. - Scene 2: Georges is very happy. - Scene 3: Georges is a bit older, using Emacs-28.3 and usually happy about it, except baffled that his CC-mode is still not supporting the latest features of C++++ despite the etc/NEWS claiming that it does. - Scene 4: Georges realizes that the problem was the old CC-mode package he had installed which took precedence over his Emacs's newer bundled CC-mode. So he removes his old CC-mode package. - Scene 5: Goerges is forced to go back to Emacs-25.4 temporarily and is annoyed that he get rid of that old CC-mode package which worked better than the even older CC-mode bundled with Emacs-25.4. By adding a "Version:" header in Emacs's bundled CC-mode package, package.el can automatically decide whether to use the bundled CC-mode package of the separately install CC-mode package based on which of the two is more recent, so Georges wouldn't hit the above problem in scene 3 and wouldn't have to remove the old CC-mode package hence could switch between 25.4 and 28.3 without problems. > 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? Not sure what you mean by "in package.el". "package.el" is a file bundled with Emacs which provides facilities to install/activate/deinstall packages and that's all. >> >> 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. I'd assume that unless you decide otherwise noone but you would change that "Version:" header (for fear of you biting their head off), so you'd get to choose those things the way you like. Personally, I'd recommend you'd upgrade the "Version:" header whenever the file has accrued enough new features or bug fixes that some users of non-master Emacs may want to install that new package in their own Emacs. > 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. You can upgrade the "Version:" header as part of some other commit. That's usually what I do. Stefan