bug#22046: [PATCH] Improve version-to-list parsing

[Alex Dunn]

The recipes MELPA uses for building packages are usually just the name,
the repository, and the method of fetching it (git, svn, etc).  To
figure out if there’s a stable version of the package, MELPA parses the
repository’s tags; if the tags aren’t valid version-strings (according
to version-to-list) it assumes there isn’t a stable version available
and packages it as “HEAD-only”.

So MELPA is at the mercy of upstream developers’ tagging practices, and
sometimes they do things like “OTP-18.0.5”: https://github.com/erlang/otp/tags

Another solution to this particular problem is for MELPA to allow their
recipes to specify a custom version schema; but my thought was that
making version-to-list more flexible was a good thing.  Parsing git tags
seems like a common enough use-case that it might be nice to have this.

But it’s true that with this change some very long strings will be
parsed as valid.  This returns '(0 9), which is sort of ridiculous:

(version-to-list "It’s true that with this change some very long strings will 
be parsed as valid: 0.9")

But I guess I’m not sure what the danger is in letting that happen.  Is
version-to-list often used to parse arbitrary strings, where false
positives would cause problems?

Thanks,
Alex

Eli Zaretskii <eliz@gnu.org> writes:

> But I've just realized that this is a followup to a previous patch, so
> let me step back and respond to that.
>
>> This was prompted by an issue over at MELPA, where they were having
>> trouble packaging stable versions of erlang-mode due to Erlang’s odd
>> version-strings: https://github.com/milkypostman/melpa/issues/2553.  So
>> with this patch, 'OTP-18.0.5' is valid and parsed as '(18 0 5).
>
> Sorry, I don't understand the issue; can you clarify?  "OTP-18.0.5" is
> not a valid version string, you are supposed to submit just the
> "18.0.5" part to the Emacs version-handling facilities.  Why isn't
> that being done here, or why cannot it be done?  Especially since the
> changes you propose effectively ignore the "OTP-" part anyway, as they
> indeed should: AFAIU, "OTP" has nothing to do with versioning.
>
> Treating "SOMETHING-1.2.3" as a valid version string changes the rules
> significantly, and IMO opens a Pandora box, as we suddenly need to be
> able to recognize/allow words that have nothing to do with versioning,
> as opposed to a few words (alpha, beta, CVS, etc.) that do.  I don't
> think we should go that way without a very good reason and some
> important use cases.
>
>> - The docstring said “22.8X3” was invalid, when it actually was; it got
>>    parsed as '(22 8 24 3).  I’ve made it really invalid.
>
> This change in behavior is definitely worth making, thanks.