ANNOUNCE: GHC 6.6 Second Release Candidate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

ANNOUNCE: GHC 6.6 Second Release Candidate

Ian Lynagh

We are pleased to announce the Second Release Candidate phase for GHC 6.6.

        Snapshots beginning with 6.5.20061001 are release candidates for 6.6

We would be particularly interested to hear whether or not the 6.6 RC
works for people who were having trouble with 6.4.2.

Also, please note that the GHC API has changed since the last RC as a
result of some feedback from the Hackathon, so you may want to check
that any applications using it still work.

Download snapshots from here:

  http://www.haskell.org/ghc/dist/current/dist/

Right now we have the source bundles:

http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src.tar.bz2
http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src-extralibs.tar.bz2

Only the first of these is necessary.  The "extralibs" package contains
various extra packages that we normally supply with GHC (and a couple of new
ones) - unpack the extralibs tarball on top of the source tree to add them,
they will be included in the build automatically.

There are also currently binary distributions for x86_64/Linux (Fedora Core
5), i386/Linux (RedHat 7(!)), and Windows.  More may appear later.

Please test as much as possible, bugs are much cheaper if we find them
before the release!

We expect to release in about a week's time.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: (Windows) ANNOUNCE: GHC 6.6 Second Release Candidate

Rene de Visser
"Ian Lynagh" <[hidden email]> schrieb im Newsbeitrag
news:[hidden email]...
>
>  http://www.haskell.org/ghc/dist/current/dist/
>
Hello Ian,

Is it on purpose that the lastest windows build does not include
cabal-install?
Since the September builds I don't see any logs for the mingw build?

Rene.

 



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Christian Maeder
In reply to this post by Ian Lynagh
Ian Lynagh schrieb:
> We are pleased to announce the Second Release Candidate phase for GHC 6.6.
>
>         Snapshots beginning with 6.5.20061001 are release candidates for 6.6
>
> We would be particularly interested to hear whether or not the 6.6 RC
> works for people

This RC works for our (about 1000) modules!

A small change between 6.5.20060919 and 6.5.20061001 regarded the
following error:

MMiSSExportFiles.hs:1:0:
    Identifier `MMiSSExportFiles.exportFiles' has conflicting
definitions in the module and its hs-boot file

where I had to replace "String" with "FilePath" in the hs-boot file to
fix this.

Cheers Christian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: (Windows) ANNOUNCE: GHC 6.6 Second Release Candidate

Duncan Coutts
In reply to this post by Rene de Visser
On Mon, 2006-10-02 at 17:06 +0200, Rene de Visser wrote:
> "Ian Lynagh" <[hidden email]> schrieb im Newsbeitrag
> news:[hidden email]...
> >
> >  http://www.haskell.org/ghc/dist/current/dist/
> >
> Hello Ian,
>
> Is it on purpose that the lastest windows build does not include
> cabal-install?

Yes that is on purpose. We decided that it was not quite ready for this
release.

We expect cabal-install to be included for wider testing in an upcoming
Cabal release. This is not so big a deal as you can upgrade Cabal
independent of ghc and you can have multiple versions of Cabal installed
at once.

Duncan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Brian Smith-3
In reply to this post by Christian Maeder
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.

Regards,
Brian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Simon Marlow-5
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.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Esa Ilari Vuokko
On 10/5/06, Simon Marlow <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Ross Paterson
On Thu, Oct 05, 2006 at 01:16:12PM +0300, Esa Ilari Vuokko wrote:
> I think that version number in repo should always be bigger than
> released version, so that snapshot names reflect versioning better.

You need to use something like setup sdist --snapshot to get an
accurate version for a snapshot, so it's not essential to increment
after release, though even-odd schemes are quite common.

> 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.)

I'd like to see the packages untangled to the point that we're no
longer checking them out of source repositories, but getting bundled
releases from some place (e.g. hackage).

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Brian Smith-3
In reply to this post by Simon Marlow-5
On 10/5/06, Simon Marlow <[hidden email]> 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.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?:

    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


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Ross Paterson
On Sun, Oct 08, 2006 at 02:48:03PM -0500, Brian Smith wrote:
> 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'm not sure which version you're looking at.  I don't recognize either
of these things in the sdist section of the Cabal User's Guide distributed
since GHC 6.4.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Brian Smith-3
On 10/8/06, Ross Paterson <[hidden email]> wrote:
On Sun, Oct 08, 2006 at 02:48:03PM -0500, Brian Smith wrote:
> 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'm not sure which version you're looking at.  I don't recognize either
of these things in the sdist section of the Cabal User's Guide distributed
since GHC 6.4.

I was looking under "latest stable version" on the Cabal website. I thought it was the latest version of the docs because the URL had "latest" in it.
I see that it is documented in later versions. But, I don't see how that mechanism would help in this situation.

Regards,
Brian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Ross Paterson
On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
> I was looking under "latest stable version" on the Cabal website. I
> thought it was the latest version of the docs because the URL had
> "latest" in it.

Hmm, quite a bit of historical stuff there.

> I see that it is documented in later versions. But, I don't see how
> that mechanism would help in this situation.

You still have to bump the version number immediately before you release.
You can bump it again immediately after you release (e.g. if you're using
Linux-style odd/even version numbering), but you don't have to, because
snapshot source distributions will have version numbers like 2.0.20061008
-- intermediate between 2.0 and 2.1, but with a date for bug tracking.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Brian Smith-3
On 10/8/06, Ross Paterson <[hidden email]> wrote:
On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
> I see that it is documented in later versions. But, I don't see how
> that mechanism would help in this situation.

You still have to bump the version number immediately before you release.
You can bump it again immediately after you release (e.g. if you're using
Linux-style odd/even version numbering), but you don't have to, because
snapshot source distributions will have version numbers like 2.0.20061008
-- intermediate between 2.0 and 2.1, but with a date for bug tracking.

Isn't that assuming that everybody gets packages from source distributions? In reality, nobody is making snapshot distributions--if somebody has a non-release version, they most likely got it directly from the repository and not from a source distribution.

- Brian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Brian Smith-3
In reply to this post by Ian Lynagh
On 10/2/06, Ian Lynagh <[hidden email]> wrote:

We are pleased to announce the Second Release Candidate phase for GHC 6.6.

I am using release candidate 2. I noticed some problems with Cabal, so I uninstalled 1.1.4 and installed the latest version from the Darcs repository. Now, programs that use the GHC library won't build:

ghc.exe: unknown package: Cabal-1.1.4 (dependency of ghc-6.5.20061001)

Does the ghc package really need exactly version 1.1.4? If so, then the Cabal README should be changed, because it tells people to uninstall old versions of Cabal before installing new versions.

From the README (http://darcs.haskell.org/packages/Cabal/README):
This is the recommended method of installing Cabal.

If you have an older version of Cabal installed, you probably just
want to remove it:

$ ghc-pkg unregister Cabal


Regards,
Brian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Duncan Coutts
On Sun, 2006-10-08 at 18:55 -0500, Brian Smith wrote:

> On 10/2/06, Ian Lynagh <[hidden email]> wrote:
>        
>         We are pleased to announce the Second Release Candidate phase
>         for GHC 6.6.
>
> I am using release candidate 2. I noticed some problems with Cabal, so
> I uninstalled 1.1.4 and installed the latest version from the Darcs
> repository. Now, programs that use the GHC library won't build:
>
> ghc.exe: unknown package: Cabal-1.1.4 (dependency of ghc-6.5.20061001)
>
> Does the ghc package really need exactly version 1.1.4? If so, then
> the Cabal README should be changed, because it tells people to
> uninstall old versions of Cabal before installing new versions.

A compiled package needs exactly the version of its deps that it was
built against. So you can't remove a dependent package without
rebuilding the packages that depend on it.

> From the README (http://darcs.haskell.org/packages/Cabal/README):
> This is the recommended method of installing Cabal.
>
> If you have an older version of Cabal installed, you probably just
>
> want to remove it:
>
>   $ ghc-pkg unregister Cabal

Yes, you're quite right. We should advise people to keep the old version
about. It should be no problem to have several versions installed.

It might also be helpful if ghc-pkg warned if you're unregistering a
package that other packages depend upon.

Duncan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: GHC 6.6 Second Release Candidate

Simon Marlow-5
In reply to this post by Brian Smith-3
Brian Smith wrote:

> On 10/8/06, *Ross Paterson* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
>      > I see that it is documented in later versions. But, I don't see how
>      > that mechanism would help in this situation.
>
>     You still have to bump the version number immediately before you
>     release.
>     You can bump it again immediately after you release (e.g. if you're
>     using
>     Linux-style odd/even version numbering), but you don't have to, because
>     snapshot source distributions will have version numbers like
>     2.0.20061008
>     -- intermediate between 2.0 and 2.1, but with a date for bug tracking.
>
>
> Isn't that assuming that everybody gets packages from source
> distributions? In reality, nobody is making snapshot distributions--if
> somebody has a non-release version, they most likely got it directly
> from the repository and not from a source distribution.

Ian is going to bump the version of all packages for 6.6.

I agree that we should also establish a versioning convention.  Ross's
suggestion is to use 'sdist --snapshot' to ensure that the version number of a
post-release version is greater than the release version number.  I think this
will be inconvenient: if I need to install a new version of a package to satisfy
some dependency and the package isn't officially released yet, I have to get it
from darcs, 'setup sdist --snapshot', and build from the snapshot rather than
just building from darcs.

The even/odd versioning scheme works well in these situations.  However, we
don't necessarily need to be that strict: just having the convention that the
version is bumped for a release and bumped immediately after the release is good
enough.  Development versions could additionally be tagged with '-devel' or '-head'.

The "extra" packages will be decoupled from GHC, so I expect in the future we'll
just use tarballs or stable repositories for these, if we ship them at all.  For
the core packages we'll probably still need our own repositories, and we'll
continue to branch them for each major GHC release, but we'll coordinate with
everyone else (eg. Hugs or standalone releases) for version numbering of these
packages.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users