Re: MELPA version numbers

[Steve Purcell <steve@sanityinc.com>]

On 1 Aug 2013, at 21:57, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>> 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".
> 
> I like this approach in abstract, but if Melpa just switches to it, all
> existing users will have to know somehow to reinstall all installed
> packages manually. Otherwise, they won't ever update, for the same
> reason as why you're bringing up this issue.


I'm personally open to switching MELPA over to a different numbering scheme if practicable.

I'm concerned, though, that the suggested scheme has significant potential for problems.

Firstly, when there *is* an author-assigned version, it must be visible in the checked-in code for MELPA to see, and not filled in by a release script. This is conspicuously not the case for a large number of libraries which we currently package, and it's obviously no good for us to silently default to 0.0 in those cases, because that would lead to uninstallable (low-versioned) MELPA packages.

A related loophole is that non-authors can take someone's v0.1 library, hack it, and then upload the resulting package to Marmalade as v0.2. (Yes, this happens!) MELPA would then continue to build uninstallable point releases of v0.1 from the author's SCM repo until the Marmalade issue is resolved.

-Steve