Compiler Versions

[Simon Marlow]

> > type Branch  = [Int]
> > data Version = Release Branch | Snapshot Branch ClockTime
> 
> This seems to me far too dependent on GHC.

I see it more as a CVS-like versioning scheme than a GHC-like scheme.
It follows a pattern that many projects are using these days.

> I suggest that abstract or
> not, each Version value contains the following information:
> The format of "tags" should
> be entirely up to the vendor
>     branch :: [Int]
>     date :: ClockTime
>     tags :: [String]
> 
> Other information should be included as well of course, but is not
> relevant to this discussion.
> 
> Information about whether something is (in GHC-speak) a "release" or
> a "snapshot" should properly be in (tags).  But other people 
> should not
> be obliged to use the GHC distinction between "release" and 
> "snapshot".

The difficulty with this is how to construct a value of type Version.
In your scheme, I need to know the release date for each version, or the
library needs to have an appropriate mapping so that it can implement
the Read instance for Version.  This is why I left out the date from
released versions in my scheme - but the disadvantage is that some
versions become imcomparable.  eg. I can't prove that a snapshot along
the 6.2 branch is later or earlier than a particular release along that
branch, but it is definitely later than 6.1.x and earlier than 6.3.x.  I
think this is reasonable.

> There are two natural orderings, namely by branch and by 
> clocktime, but
> there's not really a lot you can do about that.  It is 
> entirely plausible
> version 6.2.2 of something should have a release date after 6.4.
> (If, for example, a number of Luddites have still to convert 
> to 6.4, but
> need a bug fixed.)  My vote would be for making Ord compare date first
> (since that is a linear value), then branch, and then tags, but I can
> see that other people may have different equally valid 
> opinions.  In any
> case there's not a whole lot of point arguing about it.

Since versions are tree-shaped, it's going to be impossible to find an
appropriate Ord instance that does the right thing all the time.
Arguably it should be a partial ordering where only versions along the
same branch of the tree are comparable, but in practice I need to
compare versions like 4.08.2 and 6.2.1 and come up with the result LT,
but knowing that I can do this depends on GHC's development strategy.  

I agree it's not worth arguing, it's more important to decide whether we
can implement Read Version.

> The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as
> "6.2.20040413" is a vile hack which this discussion should certainly
> ignore!

Well, I didn't actually specify a concrete syntax for my Version type.

Cheers,
	Simon