MELPA version numbers

[Stefan Monnier <monnier@iro.umontreal.ca>]

[ 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