Re: MELPA version numbers

[Steve Purcell]

On 1 Aug 2013, at 21:57, Dmitry Gutov <address@hidden> wrote:
> 
> Stefan Monnier <address@hidden> 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