From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sebastian Wiesner Newsgroups: gmane.emacs.devel Subject: Re: MELPA version numbers Date: Fri, 2 Aug 2013 10:26:33 +0200 Message-ID: References: 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 1375432000 31888 80.91.229.3 (2 Aug 2013 08:26:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Aug 2013 08:26:40 +0000 (UTC) Cc: Steve Purcell , Donald Curtis , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 02 10:26:42 2013 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 1V5Ah7-00027Q-P0 for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2013 10:26:41 +0200 Original-Received: from localhost ([::1]:33051 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Ah6-0004Hi-UN for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2013 04:26:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Ah1-0004EN-RB for emacs-devel@gnu.org; Fri, 02 Aug 2013 04:26:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5Agz-0001dl-Uj for emacs-devel@gnu.org; Fri, 02 Aug 2013 04:26:35 -0400 Original-Received: from mail-qe0-x236.google.com ([2607:f8b0:400d:c02::236]:46504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Agz-0001dg-R7 for emacs-devel@gnu.org; Fri, 02 Aug 2013 04:26:33 -0400 Original-Received: by mail-qe0-f54.google.com with SMTP id 1so181310qee.41 for ; Fri, 02 Aug 2013 01:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ol653v+Yz7RMrbQUSvPUtn2ckpXI1qsUombm68HIsR8=; b=wjincBbElcDY5V+l6Y39eV6g5qRIwcIxtAXNoqWBI5nKEen30NHeywoorTrRcHulrO 8Hcnhm+4LtrkEHVAQUCxzwrgHo+1tMs+sWZJsI0ssqQPfN9lYrUeAioNxTFuKT0Ae612 kczBk2/IyCyi1KZnpZRrys/+TD6d1CbJhRe7u8ZoVBNh/TkbBfv5LTgDPdgv19Q3g0dH 6aa6q7MLmt2Mn5bzgAyG99qb6bFJjdh2Ksmo2fDIrC8u4KH6Fcfffp32ZmbwKxPjFe3l Yeg7aF9eD3wnGT6HyJrP4a5F+gxwRojyBu1DXrkFJi+9AZneywK9cN+Ad2G9cr8ADdhr qJhw== X-Received: by 10.229.184.71 with SMTP id cj7mr1669775qcb.60.1375431993459; Fri, 02 Aug 2013 01:26:33 -0700 (PDT) Original-Received: by 10.224.21.136 with HTTP; Fri, 2 Aug 2013 01:26:33 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c02::236 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:162367 Archived-At: 2013/8/1 Stefan Monnier : >> I think, ultimately this is not an MELPA problem, but a shortcoming of >> package.el. One of many others=E2=80=A6 > > Clearly, that's another way to look at it. After all, package evolution > is not always linear, so we may/will hit similar problems sooner or > later, kind of like what happened back then with Ispell-4. > > But these non-linearities are exceptions, whereas the issue here is > between different version numbers used for the very same > linear evolution. > > A solution to both non-linearities cold be to add release-time as > a package-property. So package.el could then warn the user "there's > a newer package with an older version number, you might want to look at > it". That's not what I meant. I don't think that the problem is in versioning at all. Rather the problem is the insufficient tracking of multiple archives in package.el. It doesn't track archives independently, and though it actually stores the origin of a package, it doesn't make any use of this information at all. These limitations sort of defeat the purpose of having multiple archives imho. Ideally, package.el would track *all* packages of *all* repositories in "package-archive-contents" (not just the latest out of all repositories), so that packages, which are contained in multiple archives, also appear multiple times in M-x list-packages, once for each archive. The user could then choose from which archive a package should be installed. And package.el would remember this choice, and look for updates only in the archive the package was installed from. If this archive is no longer contained in "package-archive-contents", package.el would warn the user, and offer to look for the package in other archives. To explicitly =E2=80=9Cswitch=E2=80=9D archives for a single package, the u= ser would just explicitly install the package from another archive, implicitly telling packages to =E2=80=9Cpin=E2=80=9D this package to the new archive f= rom now on. This more sophisticated way of tracking archives would not only neatly solve the problem of MELPA version numbers (without even touching them), but also a number of other issues with package.el, such as the popular demand to be able to explicitly choose for each package whether to use a stable release from GNU ELPA or Marmalade, or a VCS snapshot from MELPA. And it'd give *users* control about archives and the ability to choose.