
People expect the version number to uniquely identify the version of the package, so I think the Hackage revision should be included in the version number. If that means ugly version numbers: So be it, it's an incentive to tell upstream to update their code :-) Am 22.06.2017 um 21:25 schrieb Benno Fünfstück:
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
mailto:jo@durchholz.org> 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.