I'm still not sure how to handle libraries that I modified with my primops change (#6135): primitive and array. There is some discussion on the core libraries commitee list and it seems that I'll have to further modify primops, and thus primitive and array, before 7.8 is released. Should I submit my patches to maintainers of these two libraries? Also, in order to make updated versions of the libraries compatible with older versions of GHC I would need to add some #ifdef pragmas. The question is whether we and package maintainers want that compatibility or should we expect that newly released versions of primitive and array will require at least 7.8 to run? Janek ----- Oryginalna wiadomość ----- Od: "shelarcy" Do: "Herbert Valerio Riedel" DW: ghc-devs@haskell.org Wysłane: czwartek, 29 sierpień 2013 12:24:55 Temat: Re: Current state of ghc boot lib versions vs. hackage Hello Herbert, I think that current GHC HEAD's primitive and vector are undesirable version. Because: 1. GHC HEAD's primitive and vector are older than latest released version. (You already pointed out that.） 2. But ... GHC HEAD's primitive and vector have some changes from older released version (to build with GHC HEAD). 3. primitive HEAD and vector HEAD has some changes from latest release. These are not same as above GHC HEAD's changes. 4. We can't merge simd branch's primitive and vector changes before merging primive HEAD and vector HEAD' changes. (Becuase simd branch's primitive and vector depend on primitive HEAD and vector HEAD's changes.) By above reasons, I think that GHC HEAD should merge primitive HEAD and vector HEAD's changes. Best Regards, On Wed, 28 Aug 2013 00:56:08 +0900, Herbert Valerio Riedel wrote:

I've compared what versions current GHC HEAD uses w/ vs. what's currently available on Hackage (see below);

So currently, the following packages have newer versions available on hackage than are used in GHC HEAD:

- binary - containers - primitive - time - vector

In order to clarify a point that has been an issue in the past:

Can it be assumed that the GHC 7.8 feature-freeze scheduled for 14 Sept 2013[1] is also the library version freeze deadline, by which upstream package authors shall submit new package versions they want to ship as GHC boot libs w/ GHC 7.8.1? (and thus should be given an "heads-up" asap)

------------------------------------------------------------ package hackage GHC HEAD ------------------------------------------------------------ Cabal 1.18.0 == 1.18.0 array 0.4.0.1 < 0.4.0.2 base 4.6.0.1 < 4.7.0.0 bin-package-db 0.0.0.0 == 0.0.0.0 binary 0.7.1.0 > 0.7.0.0 bytestring 0.10.2.0 < 0.10.3.0 containers 0.5.2.1 > 0.5.0.0 deepseq 1.3.0.1 < 1.3.0.2 directory 1.2.0.1 == 1.2.0.1 dph-base 0.7.0.1 < 0.8.0.1 (dph-lifted-base) 0.7.0.1 < 0.8.0.1 (dph-lifted-boxed) - 0.8.0.1 (dph-lifted-copy) 0.7.0.1 < 0.8.0.1 (dph-lifted-vseg) 0.7.0.1 < 0.8.0.1 (dph-prim-interface) 0.7.0.1 < 0.8.0.1 (dph-prim-par) 0.7.0.1 < 0.8.0.1 (dph-prim-seq) 0.7.0.1 < 0.8.0.1 filepath 1.3.0.1 < 1.3.0.2 (ghc) 7.6.3 < 7.7.20130826 ghc-prim 0.3.0.0 < 0.3.1.0 haskeline 0.7.0.3 < 0.7.0.4 (haskell2010) 1.1.1.0 == 1.1.1.0 (haskell98) 2.0.0.2 < 2.0.0.3 hoopl 3.9.0.0 < 3.10.0.0 hpc 0.6.0.0 < 0.6.0.1 integer-gmp 0.5.0.0 < 0.5.1.0 old-locale 1.0.0.5 == 1.0.0.5 old-time 1.1.0.1 == 1.1.0.1 pretty 1.1.1.0 == 1.1.1.0 primitive 0.5.0.1 > 0.4.0.1 process 1.1.0.2 < 1.2.0.0 random 1.0.1.1 == 1.0.1.1 rts 1.0 == 1.0 template-haskell 2.8.0.0 < 2.9.0.0 terminfo 0.3.2.5 == 0.3.2.5 time 1.4.1 > 1.4.0.2 transformers 0.3.0.0 == 0.3.0.0 unix 2.6.0.1 < 2.7.0.0 vector 0.10.0.1 > 0.9.1 xhtml 3000.2.1 == 3000.2.1 ------------------------------------------------------------

Cheers, hvr

[1]: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8

-- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hello Jan, As far as I can tell, this should be handled using the standard procedure for externally maintained bootstrap libraries: http://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream You should coordinate with Roman about this. In the worst case, you can manually make a new (GHC-specific) release yourself, on the new version.

Also, in order to make updated versions of the libraries compatible with older versions of GHC I would need to add some #ifdef pragmas. The question is whether we and package maintainers want that compatibility or should we expect that newly released versions of primitive and array will require at least 7.8 to run?

Yes, the backwards compatibility should be done. Edward