On Monday 26 February 2007 10:52, Ross Paterson wrote:
On Sun, Feb 25, 2007 at 06:19:55PM +0100, Sven Panne wrote:
Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?
YYYYMM and YYYYMM.DD?
Fine with me. The date should probably be the build date in a first step. GHC'S build system is currently trying to be clever by asking darcs about the latest change and using that date, but this a bit of a hack at the moment and doesn't e.g. take into account the packages IIRC.
Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package?
For releases, we'd want a table of versions; we'd also want that in the release notes.
I think a file containing lines like core base ??? core Cabal ??? extra OpenGL ??? extra http://www.cs.york.ac.uk/fp/darcs/polyparse ??? ... might do the trick, with the first column describing the status of the package and the second column the place to get the bleeding edge version of it (non-http: repositories can be calculated via the repository for hugs itself, see the darcs-all script for GHC, nhc98 lacks this feature). The tricky part is the third column, describing the released version to use for release builds. I guess we should use hackage somehow, but currently I fail to see how... :-( Any suggestions? Cheers, S.