The "laws" for valid Eq/Ord instances were argued about recently but the H98 report seems reasonably clear that (==) is supposed to test for equality and the compare method is supposed to define a total ordering. There is also an implied but not explicitly stated law that:

(x == y = True) <-> (x `compare` y = EQ)

and also this I guess..

(x == y = False) <-> ~(x `compare` y = EQ)

This law is implied by the Eq constraint on the Ord class (which seems to serve no purpose otherwise).

Change History (30)

The conclusion of the discussion was that we should either remove the tags completely, or at minimum change the Eq instance to consider only the versionBranch. I was going to put a proposal to removing them through the libraries submission process. I suppose I should get round to doing that.

I saw no summary of the voting/discussing there; I meant a summary in the sense of

At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision.

Add Data.Version.makeVersion & `IsList Version`
These two facilities provide some means to avoid the double-breakage caused by
first by the deprecation (see #2496), and then again by the actual future
field-removal.
See also
https://groups.google.com/d/msg/haskell-core-libraries/q9H-QlL_gnE/4lbb_mBjre8J
for details about this library addition.
Reviewed By: ekmett
Differential Revision: https://phabricator.haskell.org/D577

I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the VersionTags field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in Setup.hs. So that the showVersion function can print something like MySoftware 2.3.0.0-ce78942aed, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in PackageDescription to keep extra notes?

My suggestion would be that this kind of extra info should go into either the existing generated Paths module, or another generated module. You can do this now with custom code in Setup.hs, but I'm sure we'd welcome a patch to Cabal to make this easier.

I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the VersionTags field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in Setup.hs. So that the showVersion function can print something like MySoftware 2.3.0.0-ce78942aed, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in PackageDescription to keep extra notes?

I also share the same feeling and sorry for being late to comment here. This is quite a common pattern out there. Removing versionTags to avoid the Eq/Ord inconsistency seems like the easiest approach but not the best one, imho. Why not stick to ​http://semver.org: MAJOR.MINOR.PATCH(-PRERELEASE)?(+tag)*, where:

"Pre-release versions have a lower precedence than the associated normal version"

"Build metadata SHOULD be ignored when determining version precedence"

One reason for not following semver exactly is that the PVP doesn't line up exactly with semver. Both of our first two digits are "major", and we allow as many subsequent digits as we want. We also don't have an observable prerelease tag for better or worse.

As for version tags being ignored by the Eq instance. That would have been a viable alternative, but it would have meant that Version still didn't line up with what we use it for in ghc, cabal, and elsewhere. IIRC the main use of the tags currently is to talk about a version "*" in some internals in places.

A "structural" Eq has the benefit that x == y implies f x == f y, and doesn't require the user to track the exception to the semantics they expect for equality, whereas under your suggestion we'd lose that.

It'd just be 'some place to shove extra stuff' bolted onto a data type that could be fundamentally simpler. Then if users want to work with a tagged version they can build it by one of several means, for whatever notions of tags they want to allow, using the existing Version type as a primitive component in their own tagged version type with tags being relevant or not for equality as they choose.

At least from my own perspective, I think removing versionTags to retain some properties is rational (well to be honest in this particular case I don't even care). And, exactly as Edward said, I just need a replacement. So I simply did as little change as in ​https://github.com/haskell/cabal/pull/2584 to accomplish that.

While cleaning up things for the 8.0 release I noticed a TODO in Data.Version mentioning this ticket. My read of this discussion is that the original plan was to remove versionTags (at least from the Eq instance, if not the field itself) in GHC 7.12 (now 8.0). This has not yet happened. It would be nice to have some guidance from the Core Libraries Committee regarding what is slated to happen on this front in this release.

Sounds good to me. Perhaps this should be added to the Core Library Committee's roadmap (which I seem to recall seeing at one point but am now having bit of trouble finding; perhaps we could add a few more inward-links to this page?)