[Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently

[Joachim Durchholz]

Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:
> On 23 June 2017 at 05:07, Joachim Durchholz <jo at durchholz.org> wrote:
>> I'd like to recommend the approach taken by Linux distros: If the package is
>> modified vs. the original code, use a version numbering scheme that clearly
>> indicates both the original version and a "packaging revision number".
>> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
>> updates should really be three revisions:
>>    happy-1.19.5 (original version uploaded by Simon)
>>    happy-1.19.5-hackage-1 (2015 update)
>>    happy-1.19.5-hackage-2 (2017 update)
> 
> The problem being that Data.Version has deprecated the tags field, so
> we can't have that format.

I gather that the tags are about to be dropped because they don't 
participate in ordering, violating either Eq or Ord requirements.
Tags could be included in ordering to fix that; however, this would get 
the wrong order when comparing these two:
   1.19.5-hackage-9  -> ([1, 19, 5), ["hackage", "9"])
   1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"])

The standard version comparison semantics is:
* Split the string at digit/nondigit boundaries into subsequences
* Digit subsequences are always greater than nondigit ones (this deals 
with projects that release 1.19 initially and then continue with 1.19.1, 
and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0)
* If both subsequences are digits, use numeric comparison, otherwise use 
string comparison.

This turns
   1.19.5-hackage-2
into
   1
   .
   19
   .
   5
   -hackage-
   2

This looks weird, but not so much if you consider that in practice, you 
never write down or see individual components but prefixes:
   1
   1.19
   1.19.5
   1.19.5-hackage
   1.19.5-hackage-2

Version comparison specs usually omit the following situations because 
you never care about them in practice:
- how to compare "007" and "7" (there are arguments for all three of <, 
=, and > so you can expect inconsistencies between ecosystems here)
- whether to handle punctuation differently from letters or not (usually 
it's "use the simplest implementation", i.e. handle them as if they were 
letters)
- how to deal with Unicode characters in nondigits subsequences (again, 
"simplest implementation", i.e. just use ByteString semantics)

Disclaimer: The above is what I have been observing the version number 
comparisons converge to, in the the Linux package and the Java library 
ecosystems. Reports about ecosystems with different version "number" 
comparison conventions would be interesting to me.

> What about just appending one extra version field (assuming PVP, so
> bump/add field n >= 5) ?

I don't know what PVP and n are in this context.