From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: ELPA new package timidity Date: Mon, 27 Jan 2014 18:51:02 +0100 Message-ID: <877g9le2k9.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1390844855 9504 80.91.229.3 (27 Jan 2014 17:47:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2014 17:47:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 27 18:47:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7qHc-0004Xg-G6 for ged-emacs-devel@m.gmane.org; Mon, 27 Jan 2014 18:47:40 +0100 Original-Received: from localhost ([::1]:60974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7qHc-0002Qc-01 for ged-emacs-devel@m.gmane.org; Mon, 27 Jan 2014 12:47:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7qHR-0002Pk-Kp for emacs-devel@gnu.org; Mon, 27 Jan 2014 12:47:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7qHK-0001dJ-5y for emacs-devel@gnu.org; Mon, 27 Jan 2014 12:47:29 -0500 Original-Received: from smtp206.alice.it ([82.57.200.102]:18708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7qHJ-0001cy-Rs for emacs-devel@gnu.org; Mon, 27 Jan 2014 12:47:22 -0500 Original-Received: from zigzag.favinet (95.244.64.57) by smtp206.alice.it (8.6.060.28) id 529A678F0C366804 for emacs-devel@gnu.org; Mon, 27 Jan 2014 18:47:20 +0100 Original-Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1W7qL5-0003Pg-MU for emacs-devel@gnu.org; Mon, 27 Jan 2014 18:51:15 +0100 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.102 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169175 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Recently (a week or two ago), i added ascii-art-to-unicode.el to GNU ELPA as package =E2=80=98ascii-art-to-unicode=E2=80=99. This was accomplis= hed in one commit, having previously made the adaptations to ELPA from the previous released version locally. After a day or so, i saw that the package appears in the "list of packages" page, with the proper version number. Cool. Now, i would like to add gnugo.el and some related files as package =E2=80=98gnugo=E2=80=99, but this time, i'd like to do the adaptations publ= icly, over several commits. In this case, it would be unseemly to have the package appear in the list of packages during this phase. I understand that the ELPA maintenance scripts trigger on change of =E2=80=98Version=E2=80=99 hea= der, from this packages/README excerpt: This cron job only creates a new package when the "version" (as specified in the foo-pkg.el or in the "Version:" header) of a package is modified. This means that you can safely work on the next version here without worrying about the unstable code making it to GNU ELPA, and simply update the "version" when you want to release the new code. But it's not clear to me that the initial commit, where =E2=80=98Version=E2= =80=99 makes the transition from non-existent to existing-but-not-ready-yet, won't trigger the new-package process. In sum, steady-state OKAY, boundary condition behavior HMMM. So, given A -- B -- C -- D where A through C have the "work in progress" version and D has the "fully adapted" version, what must i do to ensure that only D triggers the "new package" process, and not A through C? =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) =3D> nil --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLmnIsACgkQZwMiJEyAdQKdAwCgg8w7su5QF2+cYvL6jdy/l9/V ViEAoLg9Jrx0BDepBwvaFSBKkpt943Pi =+QwF -----END PGP SIGNATURE----- --=-=-=--