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

[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)

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.

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> 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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170623/43daa45e/attachment.html>