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

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 mailto:jo@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 mailto:jo@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.