On 10/5/06, <b class="gmail_sendername">Simon Marlow</b> <<a href="mailto:simonmarhaskell@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">simonmarhaskell@gmail.com</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Win32-2.0 was never officially announced or tagged, as far as I'm aware. Is<br>that right? So can't the Win32 package included with GHC 6.6 be called version 2.0?<br><br>We have branched all the packages for GHC 6.6. This does I suppose constitute a
<br>release of all these packages, in the absence of any other release and tagging<br>mechanism in use. When packages start having indepdendent release cycles, when</blockquote><div><br>Only the core libraries are on the branch, not the extra libraries.
<br><br>Regarding Win32, if the version shipped with GHC 6.6 is going to be 2.0, then the version that shipped with Hugs has to be considered less than 2.0 (because Hugs Sept 2006 was released Sept. 21, and Win32 2.0 was modified after that date). This isn't a great example because most people don't care about getWindowsDirectory, etc.
<br><br>I think that compiler release should only ship with "release" versions of libraries, with no patches.<br><br>Also, I think that at a minimum, if a package was shipped with 6.4.2, then was modified, and is still shipping in
6.6, then its version number needs to be incremented. For these packages, the version number from the 6.4.2 release is the same as the version number from the 6.6 release. Does that mean that none of these libraries changed at all since
6.4.2 was released?:<br><br> fgl-5.2, haskell-src-1.0, objectio-1.0, QuickCheck-1.0,<br> rts-1.0, haskell98-1.0, HUnit-1.1, mtl-1.0<br><br>The problem I am hoping to avoid is having somebody build packages with 6.6, create a Cabal file with a "Build-depends" that works allows "setup configure / setup build" to work with
6.6, and allows "setup configure" to work on 6.4.2, but then "setup build" fails because the packages were modified without changing the version numbers.<br><br>Finally, something was mentioned about the Cabal version number only being accurate for when somebody uses Cabal sdist --snapshot mechanism. However, this isn't documented, and the documentation for "sdist" claims that it doesn't work for most Cabalized packages (which use the simple build infrastructure). I think that a better solution is to:
<br> * update the Cabal version number of the package to whatever the release version is<br> * record and send the change in Darcs<br> * tag the release in Darcs<br> * update the Cabal version number again, to something that is "obviously" not a release version number.
E.g. "2.0.1-head"<br> * record and send the change in Darcs<br><br>When people see a version like "XXX-head," they will know it isn't a release. <br><br>Regards,<br>Brian<br><br></div></div>