I prefer George's idea of an abstract version type which is an instance of Show, Read and Ord. I'd probably also add majorVersion and minorVersion functions, which could return perhaps the same abstract type.
Sounds good to me.
Using an abstract version type seems to be the best choice for the reasons you give. However, there's a compromise here:
- If you have an abstract version type for the version of entity X, then you need one version type for each X, because they have different versioning policies. (e.g. we can't use the same version type for the version of the Haskell language and the version of the compiler, or versions of libraries).
Can't we solve that problem with classes? class (Show a, Read a, Ord a) => Version a where version :: a majorVersion :: a -> a minorVersion :: a -> a Each entity (language, compiler, library) can indeed define its own versioning type and policy, with this abstract interface. It just needs to publish the name of the concrete type that implements it.
Perhaps the best choice is to pick a policy that is as unrestrictive as possible.
I don't think we need to force a uniform policy. All we need is those few constraints in the class definition - namely partial ordering of versions, printability, and readability. Regards, Malcolm