Re: MELPA version numbers

[Stefan Monnier]

> 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…

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