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
Simon Marlow wrote (snipped):
I agree it's not worth arguing, it's more important to decide whether we can implement Read Version.
Why is the Read instance for Version so important? I don't really see one using it much. The only occasion I can imagine when you would actually want to create a Version value for GHC is when you send a new release out the door. I don't really the instance of Ord being that important either. What one wants to know is whether (1) version X was released later than some given date; (2) version X is lexicographically subsequent to [sequence of integers] (so GHC 6.02.1 comes after GHC 4.08.1); (3) version X is a subversion of [sequence of integers], as 6.2.1 is a subversion of 6.2; (4) version X has a tag attached meaning "DANGER. Do not use unless your name is Simon". Some way of converting a Version value to a short form (as in "GHC 6.02.1 (simony,hacked_for_windows) 13th April 2004") might be useful. For example you could do that with a date-like format string. Also you need some way Haskell can write a Version to a file so that it can be read again. But I think it's much more important to approach this from the angle of how people will actually want to use Version, instead of asking "How will we fit this into the standard Haskell classes?"
participants (2)
-
George Russell -
Simon Marlow