Gearing up (again) for the next release: 2014.2.0.0
Mateusz Kowalczyk
fuuzetsu at fuuzetsu.co.uk
Sun Mar 30 22:12:02 UTC 2014
On 30/03/14 21:44, Carter Schonwald wrote:
> Mark: will we try to have hp use 7.8.2? A whole bunch of bug fixes are
> planned for that,
> and likewise the patches for simplifying the cpp configuration as part of
> the settings files are slated for 7.8.2
>
I'd also like to recommend that 7.8.2 is used for similar reasons.
> On Sunday, March 30, 2014, Mark Lentczner <mark.lentczner at gmail.com> wrote:
>
>> SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8...
>> I'd like to get going on nailing down package versions.
>>
>> I've been working intently on the new Haskell Platform build process (see
>> the new-build branch<https://github.com/haskell/haskell-platform/tree/new-build>),
>> and have been building platforms against the release. Here is the
>> description of versions I'm working with:
>>
>> [ incGHC "7.8"
>> , incGHCLib "array" "0.5.0.0"
>> , incGHCLib "base" "4.7.0.0"
>> , incGHCLib "bytestring" "0.10.4.0"
>> , incGHCLib "Cabal" "1.18.1.3"
>> , incGHCLib "containers" "0.5.4.0"
>> , incGHCLib "deepseq" "1.3.0.2"
>> , incGHCLib "directory" "1.2.0.2"
>> , incGHCLib "filepath" "1.3.0.2"
>> , incGHCLib "haskell2010" "1.1.1.1"
>> , incGHCLib "haskell98" "2.0.0.3"
>> , incGHCLib "hpc" "0.6.0.1"
>> , incGHCLib "old-locale" "1.0.0.6"
>> , incGHCLib "old-time" "1.1.0.2"
>> , incGHCLib "pretty" "1.1.1.1"
>> , incGHCLib "process" "1.2.0.0"
>> , incGHCLib "template-haskell" "2.9.0.0"
>> , incGHCLib "time" "1.4.1"
>> , incGHCLib "transformers" "0.3.0.0"
>>
>> , notWindows $ incGHCLib "unix" "2.7.0.1"
>> , onlyWindows $ incGHCLib "Win32" "2.3.0.1"
>>
>> , incLib "async" "2.0.1.5"
>> , incLib "attoparsec" "0.10.4.0"
>> , incLib "case-insensitive" "1.1.0.3"
>> , incLib "cgi" "3001.1.7.5"
>> , incLib "fgl" "5.4.2.4"
>> , incLib "GLUT" "2.5.0.2"
>> , incLib "GLURaw" "1.4.0.0"
>> , incLib "haskell-src" "1.0.1.5"
>> , incLib "hashable" "1.2.1.0"
>> , incLib "html" "1.0.1.2"
>> , incLib "HTTP" "4000.2.10"
>> , incLib "HUnit" "1.2.5.2"
>> , incLib "mtl" "2.1.2"
>> , incLib "network" "2.4.2.2"
>> , incLib "OpenGL" "2.9.1.0"
>> , incLib "OpenGLRaw" "1.4.0.0"
>> , incLib "parallel" "3.2.0.4"
>> , incLib "parsec" "3.1.5"
>> , incLib "primitive" "0.5.2.1"
>> , incLib "QuickCheck" "2.6"
>> , incLib "random" "1.0.1.1"
>> , incLib "regex-base" "0.93.2"
>> , incLib "regex-compat" "0.95.1"
>> , incLib "regex-posix" "0.95.2"
>> , incLib "split" "0.2.2"
>> , incLib "stm" "2.4.2"
>> , incLib "syb" "0.4.1"
>> , incLib "text" "1.1.0.0"
>> , incLib "unordered-containers" "0.2.3.3"
>> , incLib "vector" "0.10.9.1"
>> , incLib "xhtml" "3000.2.1"
>> , incLib "zlib" "0.5.4.1"
>>
>> , incTool "cabal-install" "1.18.0.3"
>> , incTool "alex" "3.1.2"
>> , incTool "happy" "1.19.2"
>>
>> , incTool "hscolour" "1.20.3"
>> , incTool "haddock" "2.14.0"
Haddock 2.14.0 was effectively an internal release. If the platform were
to be released today, you should be using 2.14.1. It contains some extra
bugfixes. Following up on my request for waiting until 7.8.2, this will
again go up after further bugfixes follow (at the moment doc building is
broken for certain packages due to some Clang problems).
>> ]
>>
>> However, there are some issues to contend with:
>>
>> *Haddock* - is there any reason not to use the version built and
>> distributed with GHC 7.8?
There is no reason to do so as long as you pick the release with the
various bugfixes in place.
>> *Shipped w/GHC* - GHC 7.8 ships with several more packages than we
>> include in the platform. I want to review how these are handled:
>>
>> *possibly include in platform*
>>
>> - binary-0.7.1.0
>> - ghc-prim-0.3.1.0
>> - hoopl-3.10.0.0
>>
>> *shouldn't include in platform*
>> - bin-package-db-0.0.0.0
>> - integer-gmp-0.5.1.0
>> - rts-1.0
>>
>> *shipped with GHC, but not registered in pkg-db, yet possible useful to
>> include in platform:*
>>
>> - haskeline-0.7.1.2
>> - terminfo-0.4.0.0
>> - xhtml-3000.2.1 -- already in platform, but HP re-builds it...
>> seems silly?
>>
>> *cgi* - no longer builds, and we've been unwilling to bring it forward
>> because it pulls in MonadCatchIO-mtl
>>
>> *hscolour* - never approved as part of platform, but we use it to
>> generate the haddock in both GHC and the Platform - shouldn't we just
>> include it?
>>
>> *New packages:*
>> Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8
>> and the new Builder classes, caused us to delay them. Shall we include:
>>
>> aeson
>>
>> dlist (needed by aeson, which version?)
>>
>> scientific (needed by aeson - or get aeson to subsume that code?)
>>
>> *anything else? now's the time to propose!*
>>
>>
>> - Mark
>>
>>
+1 for aeson merely because there are so many packages nowadays that
depend on it, it seems like it would be a worthwhile addition but I
don't have strong feelings otherwise.
--
Mateusz K.
More information about the Libraries
mailing list