Hi, On 2017-06-22 at 18:59:31 +0200, Benno Fünfstück wrote:

At the very least, we should make sure that each revision is accompanied by an upstream PR if it is for the latest release (or any other still supported branch) and the project is hosted on some VCS service that supports PRs.

Yes! It's obviously good practice to inform maintainers about problems with their meta-data which require changes! And in fact, here's the ticket where it was discussed for entropy https://github.com/TomMD/entropy/issues/32 ...and as for happy (since I'm in frequent communication with Simon) I just left a note to pursue this at our next discussion https://github.com/simonmar/happy/issues/61#issuecomment-309669819 Cheers, Herbert

That should be read as "if (... And ...)" So I'm not recommending to force anyone to use a public VCS, I only wanted to express that revisions should be fine if there is no way to contact upstream devs (no public VCS was just an example here) MarLinn schrieb am Do., 22. Juni 2017, 20:20:

...

At the very least, we should make sure that each revision is accompanied by an upstream PR if it is for the latest release (or any other still supported branch) and the project is hosted on some VCS service that supports PRs.

Why "and" instead of "if"?

A VCS is certainly a good idea. But a (public) VCS service? Why? Keep in mind that Github and its clones are only one of many options for software management. So why force maintainers to keep up with yet another service if they don't really want or need it? That only reduces the number of willing contributers and forces people into systems that they won't really use, so it wouldn't even solve the problem.

I get the sentiment, but if email is good enough as a last-stage PR-queue for the Linux Kernel, we should allow package maintainers the same. If that makes it harder for them to integrate changes, that's their problem. (But one could always use a format that's easy to parse.)

Bonus: automatic "PR's" via email should be dead-easy to implement and maintain compared to all alternatives.

Cheers, MarLinn

_______________________________________________ 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.

There is an X-Revision field in the cabal file, perhaps cabal-install should display it more prominently ( is it even displayed at all right now? ) https://hackage.haskell.org/package/happy-1.19.5/happy.cabal Joachim Durchholz schrieb am Do., 22. Juni 2017, 21:08:

Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:

...

So I would welcome if we could make use of the "Hackage revisions" feature only in the utmost necessary cases, or even better, never, and always make properly versioned releases, where a change to any file implies a bump of the version, so that one can clearly see if one is dealing with the unmodified upstream code or not.

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 assumption here is that Simon will bump the version to happy-1.19.6 before uploading the fixed package. _______________________________________________ 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.

On 2017-06-22 21:07, Joachim Durchholz wrote:

Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:

...

So I would welcome if we could make use of the "Hackage revisions" feature only in the utmost necessary cases, or even better, never, and always make properly versioned releases, where a change to any file implies a bump of the version, so that one can clearly see if one is dealing with the unmodified upstream code or not.

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 assumption here is that Simon will bump the version to happy-1.19.6 before uploading the fixed package.

+1000 Regards,

Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:

On 23 June 2017 at 05:07, Joachim Durchholz 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.

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.

On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

The problem being that Data.Version has deprecated the tags field,

So, undeprecate it. AfC

Am 27.06.2017 um 07:10 schrieb Andrew Cowie:

On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic mailto:ivan.miljenovic@gmail.com> wrote:

The problem being that Data.Version has deprecated the tags field,

So, undeprecate it.

The patch that deprecates it mentions problems with Eq and Ord. I suspect the implementation is inconsistent with the axioms. Also, a list of tags independent of version numbers isn't exactly what would be needed to differentiate between two versions on Hackage, you actually need an "upstream" and a "Hackage" version number, plus maybe more version numbers if a piece of code goes through more stations. I.e. that wouldn't solve the problem, it needs to be replaced with something better.