ANNOUNCE: GHC 6.6 Second Release Candidate

[Esa Ilari Vuokko]

On 10/5/06, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> Brian Smith wrote:
> > The GHC 6.6 release candidate ships with "Win32-2.0." But, this is
> > actually Win32 2.0 plus some modifications (see recent patches).
> > Shouldn't the version number be inrcremented to be over 2.0? I think
> > that this applies to the other libraries as well.
> >
> > Also, the GHC-6.6 darcs-all script does not pull the extra libraries
> > using using any tags or from any particular branches. In the (near)
> > future, the libraries will progress beyond what is found in 6.6. At that
> > point in time, it will be difficult to reproduce the 6.6 release as
> > shipped by building from the Darcs repository.
>
> 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
> we make a GHC release we can just take the latest stable version (or branch) of
> each of the packages that we ship.

For Win32, when I wanted to increase version number, the reason not to
do it was that
we were going to get 2.0 with new Cabal-compatibility (which Win32 has had for a
while) near ghc 6.6 release and that meanwhile people should use
cabal's snapshot
feature.  I haven't touched Win32 version after that, on assumption
that ghc team would
manage the release.

I think that version number in repo should always be bigger than
released version, so
that snapshot names reflect versioning better.  I also would like to
somewhat untangle
Win32 release cycle from ghc's so that for example stable hugs build could be
reproduced (but that's assuming hugs build system managed tags on checkout.)

Best regards,
--Esa