The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary. -- Ashley Yakeley
On Mon, Jun 01, 2009 at 02:12:05PM -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
It wasn't released today -- it was released 3 weeks ago when GHC 6.10.3 was released.
Ross Paterson wrote:
On Mon, Jun 01, 2009 at 02:12:05PM -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
It wasn't released today -- it was released 3 weeks ago when GHC 6.10.3 was released.
How did an unfinished version of time end up in GHC? Why wasn't the released and announced 1.1.2.4 used? -- Ashley
Ashley Yakeley wrote:
Ross Paterson wrote:
On Mon, Jun 01, 2009 at 02:12:05PM -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
It wasn't released today -- it was released 3 weeks ago when GHC 6.10.3 was released.
How did an unfinished version of time end up in GHC? Why wasn't the released and announced 1.1.2.4 used?
Is the "time-1.1.3" in Hackage the same as the "time-1.1.3" in GHC 6.10.3? -- Ashley Yakeley
On Mon, Jun 01, 2009 at 02:45:57PM -0700, Ashley Yakeley wrote:
Is the "time-1.1.3" in Hackage the same as the "time-1.1.3" in GHC 6.10.3?
Yes, it is. I've patched it, adding the missing config.sub, config.guess and install-sh. You might like to add them to the repository and the extra-source-files field.
On Mon, 2009-06-01 at 14:39 -0700, Ashley Yakeley wrote:
Ross Paterson wrote:
On Mon, Jun 01, 2009 at 02:12:05PM -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
It wasn't released today -- it was released 3 weeks ago when GHC 6.10.3 was released.
How did an unfinished version of time end up in GHC? Why wasn't the released and announced 1.1.2.4 used?
Note that the next patch-level platform release will be using 1.1.2.4 (irrespective of the random version ghc shipped). Duncan
On Mon, Jun 01, 2009 at 02:39:04PM -0700, Ashley Yakeley wrote:
Ross Paterson wrote:
On Mon, Jun 01, 2009 at 02:12:05PM -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
It wasn't released today -- it was released 3 weeks ago when GHC 6.10.3 was released.
How did an unfinished version of time end up in GHC? Why wasn't the released and announced 1.1.2.4 used?
GHC releases use the darcs versions of all the libraries. These are then tarred up and put on hackage after the release. For the boot libraries there is a special branch created for the GHC branch, and we keep the branched versions as compatible as possible between GHC releases from that branch. For extralibs, we just use the HEAD repos. There is a plan to switch to using released tarballs of most, if not all, of the libraries. Hopefully we'll do that in time for 6.12. Either way, 6.12 won't have extralibs. Thanks Ian
On Tue, 2009-06-02 at 21:15 +0100, Ian Lynagh wrote:
For extralibs, we just use the HEAD repos.
Does this mean that the HEAD of any extralibs repo must be a working version around GHC release time, and that incremental code pushes into the repo should be avoided? What if the package version in the HEAD has not been updated, will GHC still use it even though it may have the same version number as an earlier, different release? -- Ashley Yakeley
On Tue, 2009-06-02 at 14:00 -0700, Ashley Yakeley wrote:
On Tue, 2009-06-02 at 21:15 +0100, Ian Lynagh wrote:
For extralibs, we just use the HEAD repos.
Does this mean that the HEAD of any extralibs repo must be a working version around GHC release time, and that incremental code pushes into the repo should be avoided?
What if the package version in the HEAD has not been updated, will GHC still use it even though it may have the same version number as an earlier, different release?
It shouldn't matter any more. We do not expect any more "extralibs" releases with ghc. The HP only uses existing hackage releases made by the maintainers. Duncan
On Tue, Jun 02, 2009 at 02:00:27PM -0700, Ashley Yakeley wrote:
On Tue, 2009-06-02 at 21:15 +0100, Ian Lynagh wrote:
For extralibs, we just use the HEAD repos.
Does this mean that the HEAD of any extralibs repo must be a working version around GHC release time
Yes.
What if the package version in the HEAD has not been updated, will GHC still use it even though it may have the same version number as an earlier, different release?
We increase it when necessary, e.g.:
Sat Oct 11 04:48:01 BST 2008 Duncan Coutts
On Mon, 2009-06-01 at 14:12 -0700, Ashley Yakeley wrote:
The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary.
I didn't realise it hit hackage. Perhaps we should set the hackage preferred version to <1.1.3 so that there is no need for you to rush. See http://hackage.haskell.org/packages/archive/preferred-versions Duncan
participants (4)
-
Ashley Yakeley -
Duncan Coutts -
Ian Lynagh -
Ross Paterson