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

Joachim Durchholz jo at durchholz.org
Fri Jun 23 20:13:00 UTC 2017

Am 23.06.2017 um 10:27 schrieb Benno Fünfstück:
> Why would it need to be included in the version number? Note that, 
> compared to version numbers, the revision number does not take part in 
> dependency resolution (cabal always picks the latest revision AFAIK)

Dependencies specify minimum and/or maximum revisions, so revision 
ordering is really important.

> I suggest that cabal should print something like:
> Building foo-1.2.3 (revision 2)
> If it uses a revision. This does not require the version number to 
> change, it only changes the output of cabal so it should be 
> uncontroversial and simple to implement.

I'm feeling uneasy about that, for various reasons.
1) "Revision" is a somewhat vague terminology here. It's unclear what 
kind of revision, and how that's different from a version. From what I 
gather, it's essentially just a sub-version of 1.2.3 created by the 
Hackage people instead of original upstream.
2) Having a version and a revision works fine if there are two parties 
involved (in this case: upstream and Hackage guys). The approach doesn't 
scale to more parties, which is rare but does happen.
3) Also, "revision" might not just cut it. E.g. Maven (Java's moral 
equivalent of Hackage) offers two kinds of modules, productive (never 
ever change) and snapshot (may change at the drop of the hat), and 
snapshot versions/revisions are simply marked by a SNAPSHOT part in the 
version number. If a repository offers more module categories, it will 
want to differentiate between them; since the set of categories may grow 
over time, and different repositories may offer different categories, 
you want that to be extensible.

Essentially, it boils down to "there should a single identifier for a 
specific build of a module, let's call that the module version; and 
different repositories may have different needs so a mere integer list 
doesn't but it".

 From another perspective, allowing strings in versions subsumes tags, 
but in a semantically clean way.

Just my 2 cents.

> This would increase visibility in the case that a revision is used. 
> There may be more places where this output makes sense, not just when 
> printing the Building... Message
> Regards,
> Benno
> Joachim Durchholz <jo at durchholz.org <mailto:jo at durchholz.org>> schrieb 
> am Fr., 23. Juni 2017, 10:05:
>     Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:
>      > On 23 June 2017 at 05:07, Joachim Durchholz <jo at durchholz.org
>     <mailto: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.
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     Only members subscribed via the mailman list are allowed to post.

More information about the Haskell-Cafe mailing list