From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: MELPA version numbers Date: Thu, 01 Aug 2013 17:39:35 -0400 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 1375393196 1397 80.91.229.3 (1 Aug 2013 21:39:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 21:39:56 +0000 (UTC) Cc: Steve Purcell , emacs-devel@gnu.org To: Donald Curtis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 01 23:39:57 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 1V50bB-0003Fb-5Q for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2013 23:39:53 +0200 Original-Received: from localhost ([::1]:37605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V50bA-00065j-Pd for ged-emacs-devel@m.gmane.org; Thu, 01 Aug 2013 17:39:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V50b1-00063Y-Ix for emacs-devel@gnu.org; Thu, 01 Aug 2013 17:39:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V50au-0001g5-U6 for emacs-devel@gnu.org; Thu, 01 Aug 2013 17:39:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:28094) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V50au-0001ft-Pv for emacs-devel@gnu.org; Thu, 01 Aug 2013 17:39:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABK/CFG4rw3m/2dsb2JhbABEhke4Rxdzgh4BAQQBDhUzDxQFCwsODAIYDgICFBgNJCcHh3AGrl+SToEjjAmCS4ETA6R6gV6DE4FM X-IPAS-Result: AgAFABK/CFG4rw3m/2dsb2JhbABEhke4Rxdzgh4BAQQBDhUzDxQFCwsODAIYDgICFBgNJCcHh3AGrl+SToEjjAmCS4ETA6R6gV6DE4FM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="20379492" Original-Received: from 184-175-13-230.dsl.teksavvy.com (HELO pastel.home) ([184.175.13.230]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 01 Aug 2013 17:39:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8A98663C70; Thu, 1 Aug 2013 17:39:35 -0400 (EDT) In-Reply-To: (Donald Curtis's message of "Thu, 1 Aug 2013 13:49:52 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162341 Archived-At: > 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. Yes, clearly, that would be a big cost (one-time cost, but fairly big). Maybe we could try to invent a smoother transition. E.g.: 1- use "20100105.123.2.3" instead of "2.3.20100105.123". Rebuild all packages to follow this rule. This way, most users will "upgrade" their package to the "newer" (identical save the revnb) packages, so that old-style revnb will disappear over time. 2- change package.el to recognize those special mid-style rev numbers and internally handle them as new-style "2.3.20100105.123". This way, users of old package.el get the same behavior as before, but users of newer ones get the new behavior. 3- after a few years (when you can expect most users to have upgraded their installed packages to the mid-style revnb and to use the newer package.el), switch to new-style "2.3.20100105.123". > It is also not clear in this case how to handle packages that > don't include a version number. No version could be treated like version 0.0 ? > 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. They had the same problem: they "accidentally" used a YYYYMMDD version numbering, and when they fixed that, they discovered that it prevented users from upgrading, so they had to revert to YYYYMMDD. > 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. I tend to agree that for many package, version numbers aren't that important. But they are used and I think there are good cognitive reasons for them. Ubuntu's date-based version numbers seem to strike a reasonable balance, but I don't think this could work for MELPA since the "resolution" needs to be much higher (for lack of control over the rate of releases). Tho at least for GNU ELPA, I guess we could stick to "YY.MM" release names. > 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". Stefan