On Thu, 2008-05-08 at 15:39 -0700, Isaac Potoczny-Jones wrote:

Duncan Coutts wrote: (snip)

...

Does this seem like a good idea? What is/was the rationale for tags in the first place?

Yes, if I recall, Tags were not originally supposed to affect the ordering of versions,

And actually they don't affect the ordering but they do affect equality. Yes it's inconsistent. If we look in the base library in Data.Version we find: instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 This is clearly wrong. We would expect that: a == b <=> compare a b == EQ but that does not hold here.

but meant only for human consumption. Whether changing that now is a good idea or not, it's hard to say. How many packages in Hackage have any tags, for instance?

One. It was uploaded the other day which is why I just noticed that it's a problem. Duncan

On Thu, 2008-05-08 at 16:54 -0700, Isaac Potoczny-Jones wrote:

Duncan Coutts wrote:

...

And actually they don't affect the ordering but they do affect equality. Yes it's inconsistent.

If we look in the base library in Data.Version we find:

instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order

instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2

This is clearly wrong. We would expect that: a == b <=> compare a b == EQ but that does not hold here.

Ewwwwwwwwwww.

Yeah quite :-)

Sounds like it's a good time to fix it now. I'm surprised that only one package uses tags, though.

It's clear we should drop the check on the tags from the == test but I'm not sure if we should also change the showVersion or parseVersion functions. I'm planning on changing the equivalent of showVersion in Cabal to not display the tags.

Maybe add something to the package lint during upload too?

I've attached a patch to do that and I'm cc'ing Ross so he can decide if he agrees or not. Duncan

On Fri, 2008-05-09 at 10:29 +0100, Ross Paterson wrote:

On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:

...

It's clear we should drop the check on the tags from the == test but I'm not sure if we should also change the showVersion or parseVersion functions.

I'm planning on changing the equivalent of showVersion in Cabal to not display the tags.

What are tags for?

From the code in base:

versionTags :: [String] -- really a bag -- ^ A version can be tagged with an arbitrary list of strings. -- The interpretation of the list of tags is entirely dependent -- on the entity that this version applies to.

Should we have them at all?

Getting rid of them is a bit harder because it's a data type defined in the base library.

Currently they've been used in:

hsgnutls-0.2.3-barracuda hsgnutls-0.2.3.1-barracuda regex-tdfa-0.92-ghc-68-build-fix

which seem to be non-maintainer releases. You'd want such versions to be distinguished from the untagged versions.

Perhaps so, but are tags the right way to do it? If we take them into account for equality then we have to do so for ordering too. We'd have to do something like comparing the sorted lists of tags. If we keep them I'd prefer to just carry the info around but ignore it. If we wanted to support tags we'd have to do it consistently all the way through. They do not translate into distro packages which is a great disadvantage imho. Duncan

On Fri, May 09, 2008 at 10:59:25AM +0100, Malcolm Wallace wrote:

Ross Paterson wrote:

...

What are tags for? Should we have them at all?

hsgnutls-0.2.3-barracuda hsgnutls-0.2.3.1-barracuda regex-tdfa-0.92-ghc-68-build-fix

I'm guessing that the tag generally indicates a specific set of bugfixes over the original version?

If they are ignored when comparing version numbers then that means that cabal-install won't update the package to incorporate the bug fix, which sounds bad. Build fixes would be OK from that point of view. Personally I've never liked tags. I'd be happy to remove them, even though the type is in base. Thanks Ian

On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:

I'm planning on changing the equivalent of showVersion in Cabal to not display the tags.

This sounds like it'll make for some very confusing behaviour differences, as people won't realise that they aren't using exactly the same package. Thanks Ian

On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:

I'm planning on changing the equivalent of showVersion in Cabal to not display the tags.

The hackageDB upload script rejects packages for which show of parse is not the original string (in the .cabal file, the directory name and the tarfile name). So the effect would be to ban tags.

On Wed, May 14, 2008 at 10:54:00AM +0100, Duncan Coutts wrote:

On Fri, 2008-05-09 at 19:02 +0100, Ross Paterson wrote:

...

On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote:

...

I'm planning on changing the equivalent of showVersion in Cabal to not display the tags.

The hackageDB upload script rejects packages for which show of parse is not the original string (in the .cabal file, the directory name and the tarfile name). So the effect would be to ban tags.

Yes, though a more specific error message is a bit friendlier which is why I sent the patch to do that.

OK, but if we're going to ban tags, we ought to remove them altogether (library proposal for base and all). Perhaps whoever thought tags were a good idea could present the case for them. Simon (M)?