Proposal: remove versionTags from Data.Version

[Duncan Coutts]

On Tue, 2014-09-23 at 23:57 +0200, Thomas Miedema wrote:
> Version in Data.Version from base is defined as:
> 
>     data Version = Version { versionBranch :: [Int], versionTags ::
> [String] }
> 
>     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
> 
> 
> ## Proposal
> Remove the `versionTags` field from this type.
> 
> 
> ## Motivation
> * The Eq and Ord instances of Version don't agree whether two versions
> with different
> versionTags are equal or not [1]:
> 
>     > a = Version [1] ["a"]
>     > b = Version [1] ["b"]
>     > compare a b
>     EQ
>     > a == b
>     False
> 
> * The Package versioning policy does not include version tags [2].
> * Cabal no longer supports package version tags [3,4].
> 
> Discussion period: 2 weeks.
> 
> Note: this is not a proposal to ignore trailing zeros when comparing
> versions. Neither is this is a proposal to change the Eq instance for
> Version to only consider the versionBranch field. This is a proposal to
> remove versionTags altogether.

Cabal is probably the primary user of this type. With my Cabal
maintainer's hat on I support this change.

Cabal has for a long time deprecated the version tags feature. It
accepts but ignores tags in most places, and never emits tags (Cabal
uses its own parser and printer). Packages using tags in their version
are not allowed on hackage for example.

The tags idea turned out not to really work. The fact that it's not part
of the Ord instance causes all sorts of problems (think package
indexes), but then it's not clear what an Ord instance including an
unordered set of tags should be. It does not map onto other package
system's versions (which have strings like "beta" but they're part of
the version number, not an additional unordered set).

In short, Cabal tried to make sense of the tags but it just causes too
many problems and so Cabal has for years now pretended that the tags
feature does not exist.

Duncan