From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alex Dunn Newsgroups: gmane.emacs.bugs Subject: bug#22046: [PATCH] Improve version-to-list parsing Date: Mon, 30 Nov 2015 18:09:03 -0800 Message-ID: References: <83y4dgma7k.fsf@gnu.org> <83r3j7mqpr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448935828 18621 80.91.229.3 (1 Dec 2015 02:10:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2015 02:10:28 +0000 (UTC) Cc: 22046@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 01 03:10:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1a3aOX-0006Vl-3H for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 03:10:17 +0100 Original-Received: from localhost ([::1]:44323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3aOW-0000Ez-IP for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 21:10:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3aOO-0000BS-W5 for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 21:10:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3aOJ-0007qv-VP for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 21:10:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3aOJ-0007qm-SB for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 21:10:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3aOJ-0005W5-74 for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 21:10:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alex Dunn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2015 02:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22046 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 22046-submit@debbugs.gnu.org id=B22046.144893574821036 (code B ref 22046); Tue, 01 Dec 2015 02:10:03 +0000 Original-Received: (at 22046) by debbugs.gnu.org; 1 Dec 2015 02:09:08 +0000 Original-Received: from localhost ([127.0.0.1]:33463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3aNQ-0005TD-3k for submit@debbugs.gnu.org; Mon, 30 Nov 2015 21:09:08 -0500 Original-Received: from mail-pa0-f43.google.com ([209.85.220.43]:33290) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3aNN-0005S5-Jp for 22046@debbugs.gnu.org; Mon, 30 Nov 2015 21:09:06 -0500 Original-Received: by pabfh17 with SMTP id fh17so210178731pab.0 for <22046@debbugs.gnu.org>; Mon, 30 Nov 2015 18:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=qXi5qFpPTnRYvv69OZun45xcUVwvkTYICRj2C5DWSiU=; b=oTsDO/UHaWioFW17xJOMLuxVNDbGGeEU9McZxY7hR+8TnBvBS6u2nTzkj65Edb92xm w0iVNSU5oOiVq/Dl92i+sBaLmGjb9T2NgvOZoQeQjbEQo6HYYaUTtO9ZokdpHekbdaub IU4NYEZy7oqRXE+ho35YR7+PJCKZ7Bnn4BUpHGvxEINebTUfpdfFvBlQDGIpB2ZJnTmn I5miG46iydE1njM8AaEO1nQIkZshUiyfDRx5DAO/mb9gl6Mu1yStd4f3dyhUOnr2oJph KQrkZXryRbrWbSVFbi7ziNU31Dcttefi8MWTR0VF1WsrgZmwyKS/n89SW1nYBpGZDxFc E5xw== X-Received: by 10.67.5.2 with SMTP id ci2mr95843279pad.47.1448935744554; Mon, 30 Nov 2015 18:09:04 -0800 (PST) Original-Received: from localhost (pool-98-108-240-213.snloca.dsl-w.verizon.net. [98.108.240.213]) by smtp.gmail.com with ESMTPSA id k85sm53805827pfb.59.2015.11.30.18.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2015 18:09:03 -0800 (PST) In-Reply-To: <83r3j7mqpr.fsf@gnu.org> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.50.1 (x86_64-apple-darwin15.0.0) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109483 Archived-At: The recipes MELPA uses for building packages are usually just the name, the repository, and the method of fetching it (git, svn, etc). To figure out if there=E2=80=99s a stable version of the package, MELPA parses= the repository=E2=80=99s tags; if the tags aren=E2=80=99t valid version-strings= (according to version-to-list) it assumes there isn=E2=80=99t a stable version availab= le and packages it as =E2=80=9CHEAD-only=E2=80=9D. So MELPA is at the mercy of upstream developers=E2=80=99 tagging practices,= and sometimes they do things like =E2=80=9COTP-18.0.5=E2=80=9D: https://github.= com/erlang/otp/tags Another solution to this particular problem is for MELPA to allow their recipes to specify a custom version schema; but my thought was that making version-to-list more flexible was a good thing. Parsing git tags seems like a common enough use-case that it might be nice to have this. But it=E2=80=99s true that with this change some very long strings will be parsed as valid. This returns '(0 9), which is sort of ridiculous: (version-to-list "It=E2=80=99s true that with this change some very long st= rings will be parsed as valid: 0.9") But I guess I=E2=80=99m not sure what the danger is in letting that happen.= Is version-to-list often used to parse arbitrary strings, where false positives would cause problems? Thanks, Alex Eli Zaretskii writes: > But I've just realized that this is a followup to a previous patch, so > let me step back and respond to that. > >> This was prompted by an issue over at MELPA, where they were having >> trouble packaging stable versions of erlang-mode due to Erlang=E2=80=99s= odd >> version-strings: https://github.com/milkypostman/melpa/issues/2553. So >> with this patch, 'OTP-18.0.5' is valid and parsed as '(18 0 5). > > Sorry, I don't understand the issue; can you clarify? "OTP-18.0.5" is > not a valid version string, you are supposed to submit just the > "18.0.5" part to the Emacs version-handling facilities. Why isn't > that being done here, or why cannot it be done? Especially since the > changes you propose effectively ignore the "OTP-" part anyway, as they > indeed should: AFAIU, "OTP" has nothing to do with versioning. > > Treating "SOMETHING-1.2.3" as a valid version string changes the rules > significantly, and IMO opens a Pandora box, as we suddenly need to be > able to recognize/allow words that have nothing to do with versioning, > as opposed to a few words (alpha, beta, CVS, etc.) that do. I don't > think we should go that way without a very good reason and some > important use cases. > >> - The docstring said =E2=80=9C22.8X3=E2=80=9D was invalid, when it actua= lly was; it got >> parsed as '(22 8 24 3). I=E2=80=99ve made it really invalid. > > This change in behavior is definitely worth making, thanks.