ANNOUNCE: GHC 6.6 Second Release Candidate

[Brian Smith]

On 10/5/06, Simon Marlow <simonmarhaskell at gmail.com> wrote:
>
> Win32-2.0 was never officially announced or tagged, as far as I'm
> aware.  Is
> that right?  So can't the Win32 package included with GHC 6.6 be called
> version 2.0?
>
> We have branched all the packages for GHC 6.6.  This does I suppose
> constitute a
> release of all these packages, in the absence of any other release and
> tagging
> mechanism in use.  When packages start having indepdendent release cycles,
> when


Only the core libraries are on the branch, not the extra libraries.

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.

I think that compiler release should only ship with "release" versions of
libraries, with no patches.

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.2release 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?:

    fgl-5.2, haskell-src-1.0, objectio-1.0, QuickCheck-1.0,
    rts-1.0, haskell98-1.0, HUnit-1.1, mtl-1.0

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.

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:
    * update the Cabal version number of the package to whatever the release
version is
    * record and send the change in Darcs
    * tag the release in Darcs
    * update the Cabal version number again, to something that is
"obviously" not a release version number. E.g. "2.0.1-head"
    * record and send the change in Darcs

When people see a version like "XXX-head," they will know it isn't a
release.

Regards,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20061008/c828190d/attachment.htm