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: Sun, 19 Aug 2018 19:45:52 -0400 Message-ID: References: <20180819204918.GA3934@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534722244 2174 195.159.176.226 (19 Aug 2018 23:44:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2018 23:44:04 +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 Mon Aug 20 01:44:00 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 1frXMV-0000RV-6I for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 01:43:59 +0200 Original-Received: from localhost ([::1]:44474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frXOb-0004k1-PD for ged-emacs-devel@m.gmane.org; Sun, 19 Aug 2018 19:46:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frXOW-0004jw-78 for emacs-devel@gnu.org; Sun, 19 Aug 2018 19:46:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frXOT-0002HD-3k for emacs-devel@gnu.org; Sun, 19 Aug 2018 19:46:04 -0400 Original-Received: from [195.159.176.226] (port=51429 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frXOS-0002Gr-Sn for emacs-devel@gnu.org; Sun, 19 Aug 2018 19:46:01 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1frXMJ-0000DS-OX for emacs-devel@gnu.org; Mon, 20 Aug 2018 01:43:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:T6oWRIn1B6iI/930ZLdSU5Kyu7Y= 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:228701 Archived-At: >> I just tested the construction of a GNU ELPA package for CC-mode using >> the :core thingy of elpa.git and everything looks good. > Who's going to be testing this? I've a slight suspicion that sometimes > people add things to CC Mode that depend on things in master. That would > be subotimal for ELPA. This has not proved to be a problem for other packages we handle this way (e.g. soap-client, python.el, ...). One of the reasons is that it's so cheap&quick to release a new version that such problems are trivial to solve if/when they show up. Also it's easier for contributors to discover that the package is distributed via GNU ELPA than to try and search the web for some indication that the package may be distributed separately somewhere (and then try and figure out if that other distribution site is still related to the code that's bundled with Emacs, ...), so I think contributors are more aware of this issue for those :core GNU ELPA packages. 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. >> 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. > 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. Stefan