ANNOUNCE: GHC 6.6 Second Release Candidate

Ian Lynagh

2 Oct 2006 2 Oct '06

7:29 a.m.

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

Show replies by date

Rene de Visser

2 Oct 2 Oct

11:06 a.m.

New subject: (Windows) ANNOUNCE: GHC 6.6 Second Release Candidate

"Ian Lynagh" schrieb im Newsbeitrag news:20061002112924.GA13383@matrix.chaos.earth.li...

...

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.

Duncan Coutts

5:23 p.m.

New subject: (Windows) ANNOUNCE: GHC 6.6 Second Release Candidate

On Mon, 2006-10-02 at 17:06 +0200, Rene de Visser wrote:

...

"Ian Lynagh" schrieb im Newsbeitrag news:20061002112924.GA13383@matrix.chaos.earth.li...

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

Christian Maeder

11:22 a.m.

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

Brian Smith

4 Oct 4 Oct

2:43 p.m.

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

Simon Marlow

5 Oct 5 Oct

5:48 a.m.

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

Esa Ilari Vuokko

6:16 a.m.

On 10/5/06, Simon Marlow 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

Ross Paterson

8:01 a.m.

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

Brian Smith

8 Oct 8 Oct

3:48 p.m.

On 10/5/06, Simon Marlow 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

Ross Paterson

6:22 p.m.

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.

Brian Smith

6:30 p.m.

On 10/8/06, Ross Paterson 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

Ross Paterson

6:52 p.m.

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.

Brian Smith

7:51 p.m.

On 10/8/06, Ross Paterson 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

Simon Marlow

9 Oct 9 Oct

7:01 a.m.

Brian Smith wrote:

...

On 10/8/06, *Ross Paterson* mailto:ross@soi.city.ac.uk> 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

Brian Smith

8 Oct 8 Oct

7:55 p.m.

On 10/2/06, Ian Lynagh 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

Duncan Coutts

8:11 p.m.

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

...

On 10/2/06, Ian Lynagh 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

6800

Age (days ago)

6807

Last active (days ago)

List overview

Download

15 comments

8 participants

participants (8)

Brian Smith
Christian Maeder
Duncan Coutts
Esa Ilari Vuokko
Ian Lynagh
Rene de Visser
Ross Paterson
Simon Marlow