From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Donald Curtis Newsgroups: gmane.emacs.devel Subject: Re: MELPA version numbers Date: Thu, 1 Aug 2013 13:49:52 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d100242300204e2e8fe16 X-Trace: ger.gmane.org 1375393109 1152 80.91.229.3 (1 Aug 2013 21:38:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 21:38:29 +0000 (UTC) Cc: Steve Purcell , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 01 23:38:32 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 1V50Zr-00085Q-He for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2013 23:38:31 +0200 Original-Received: from localhost ([::1]:36150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V50Zr-0005Fy-4E for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2013 17:38:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4zpU-0001EE-RE for emacs-devel@gnu.org; Thu, 01 Aug 2013 16:50:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V4zpT-0000So-7G for emacs-devel@gnu.org; Thu, 01 Aug 2013 16:50:36 -0400 Original-Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:53570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4zpS-0000SZ-Nm for emacs-devel@gnu.org; Thu, 01 Aug 2013 16:50:35 -0400 Original-Received: by mail-la0-f45.google.com with SMTP id fj20so1786327lab.18 for ; Thu, 01 Aug 2013 13:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZydR1zBZurcWVx/nwzachhT8uqCk78vyHvgSynsMbMI=; b=JbuhmDcMoiBS/+nImniisi4296e3MyF67JBsFeuGdUA17yV3vrhBImswWvYKWKAOb2 X4Ei+HxWqkeEnTNO3c8IsfgJHHQFsB10jxeYHMX1P7zFY724YfGapxLIvJFXUvyR9C17 8aI2RXaf0kwi2j9pGsSQ0fPgJ9V4PTq5x9IvyTMwDFDyGYV91GGvMOxaSbw+6TvkBZOA 60J6NzbmxSEgBj/c7kVuaNRb5znsP0biP8GTVgt4OyxeoM3eFmpkzrMULALg5Zkr/Nym sda/oIJ6VJQ/C5CyveZKhhYRrOVlr6OhWOtCrUiUYb8sW/fCtGPE8uBhCCOxQew/Ni8g ClVg== X-Received: by 10.152.5.197 with SMTP id u5mr1552268lau.59.1375390232881; Thu, 01 Aug 2013 13:50:32 -0700 (PDT) Original-Received: by 10.112.79.239 with HTTP; Thu, 1 Aug 2013 13:49:52 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: KC63JoeXn2xD71mlLu23FKTEVNA X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22d X-Mailman-Approved-At: Thu, 01 Aug 2013 17:38:27 -0400 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:162339 Archived-At: --089e013d100242300204e2e8fe16 Content-Type: text/plain; charset=UTF-8 I apologize for the difficulty of finding contact information. We try to do most dealings via GitHub which we know doesn't work for everyone. This would work as a solution except for that we would then break updates for current users in the same way that it would break if someone stopped using MELPA. It is also not clear in this case how to handle packages that don't include a version number. I'm happy to keep this discussion open as I know it affects many users as well as developers. One solution I might suggest is the approach that js2-mode has taken on the GNU repo. It seems that their versions follow with MELPA sans the time. I think that having arbitrary version numbers for things like extensions is a little overkill and MELPA is at least a little evidence that versioning based in the date of release *can* work. In this case it could be as simple as the Emacs community endorsing a release date based versioning system. On Thu, Aug 1, 2013 at 10:50 AM, Stefan Monnier wrote: > [ As is sadly becoming the norm nowadays, it's difficult to find > a contact email address at http://melpa.milkbox.net/, so I send this > here instead, hoping someone here will know where to resend it for > me. ] > > A few times now I've heard people suffer from problems due to MELPA's > use of incomparable version numbers: MELPA builds packages straight from > a DVCS branch tip, so you get the "bleeding edge" and their build script > ignores the package's own version number and instead just slaps > a version number based on the current time, such as 20100105.123. > > This system makes sense, but if the package is also available (in it's > "latest released version") via GNU ELPA or Marmalade, we have a problem > because the two version numbers can't be compared correctly, and > package.el doesn't even know it, so it just always picks MELPA's version > (since 20100105.123 is "clearly" much more recent than say 2.3). > > This mess works surprisingly well in practice, since MELPA's versions > are often at least as recent as the one on GNU ELPA or Maramalde (by virtue > of being the bleeding edge from the DVCS). > > But if you ever stop using MELPA, all your MELPA-installed packages will > stay non-updated for the foreseeable future since it'll take a while for > foo.el to go from version 2.3 to version 20100106.0. > And if for some reason the MELPA recipe points to an old DVCS > unmaintained branch, you're similarly out of luck. > > One way out of this is to change the MELPA version numbers so that > instead of ignoring the package's "2.3" and replacing it with > "20100105.123", it should replace it with "2.3.20100105.123". > > WDYT? > > > Stefan > --089e013d100242300204e2e8fe16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I apologize for the difficulty of finding contact informat= ion. We try to do most dealings via GitHub which we know doesn't work f= or everyone.

This would work as a solution except for th= at we would then break updates for current users in the same way that it wo= uld break if someone stopped using MELPA. It is also not clear in this case= how to handle packages that don't include a version number.

I'm happy to keep this discussion open as I know it= affects many users as well as developers.

One sol= ution I might suggest is the approach that js2-mode has taken on the GNU re= po. It seems that their versions follow with MELPA sans the time. I think t= hat having arbitrary version numbers for things like extensions is a little= overkill and MELPA is at least a little evidence that versioning based in = the date of release *can* work. In this case it could be as simple as the E= macs community endorsing a release date based versioning system.






On Thu, Aug 1, 2013 at= 10:50 AM, Stefan Monnier <monnier@iro.umontreal.ca> = wrote:
[ As is sadly becoming the norm nowadays, it= 's difficult to find
=C2=A0 a contact email address at http://melpa.milkbox.net/, so I send this
=C2=A0 here instead, hoping someone here will know where to resend it for =C2=A0 me. =C2=A0]

A few times now I've heard people suffer from problems due to MELPA'= ;s
use of incomparable version numbers: MELPA builds packages straight from a DVCS branch tip, so you get the "bleeding edge" and their build= script
ignores the package's own version number and instead just slaps
a version number based on the current time, such as 20100105.123.

This system makes sense, but if the package is also available (in it's<= br> "latest released version") via GNU ELPA or Marmalade, we have a p= roblem
because the two version numbers can't be compared correctly, and
package.el doesn't even know it, so it just always picks MELPA's ve= rsion
(since 20100105.123 is "clearly" much more recent than say 2.3).<= br>
This mess works surprisingly well in practice, since MELPA's versions are often at least as recent as the one on GNU ELPA or Maramalde (by virtue=
of being the bleeding edge from the DVCS).

But if you ever stop using MELPA, all your MELPA-installed packages will stay non-updated for the foreseeable future since it'll take a while fo= r
foo.el to go from version 2.3 to version 20100106.0.
And if for some reason the MELPA recipe points to an old DVCS
unmaintained branch, you're similarly out of luck.

One way out of this is to change the MELPA version numbers so that
instead of ignoring the package's "2.3" and replacing it with=
"20100105.123", it should replace it with "2.3.20100105.123&= quot;.

WDYT?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--089e013d100242300204e2e8fe16--