Re: A modest proposal (re the Platform)
On 20 January 2014 17:29, Andres Löh
(2) Simply because GHC 7.8 is itself so long delayed and so full of new features, I think it's realistic to assume that quite a few library glitches will appear even after it's released. Also, GHC bugs may be found only after formal release (despite all the hammering, the use of GHC pre release isn't quite comparable with the amount of testing it gets afterwards; IMHO, there might very well be need for a GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as possible, but how soon would that actually happen, realistically?
I know I already said "+1" but this is also a very valid standpoint. I guess the question is how long does HP want to wait for a stable ghc-7.8 release? There were already a number of important library updates planned for the HP release with ghc-7.6.3 - doing things more incrementally is also good I believe. Also as Andres mentioned in view of Mavericks. I know it is difficult but if ghc and haskell-platform could align their schedules better then things might be easier to plan in the future. Jens
Just a quick +1 for including GHC 7.8 in the next HP release. Regarding compiler features, shipping GHC 7.6.3 again would mean that the HP is still roughly at September 2012 (the first release of GHC 7.6.x). Furthermore, I don't fully buy into the argument that we should wait for 7.8 to stabilize: Power users will use something near HEAD, anyway, almost all other users will probably use the HP.
Indeed. Perhaps more importantly: many long standing problems, relating to
how ghci linking works on every major platform, and having win64 support,
look to be resolved In 7.8. These are HUGE. Additionally the Cpp that's a
bother on osx and bsd systems matter goes away for HP if the next release
is using 7.8 (especially if a wee patch I wrote to kill the problem good
this week gets merged in. )
On Thursday, January 23, 2014, Sven Panne
Just a quick +1 for including GHC 7.8 in the next HP release. Regarding compiler features, shipping GHC 7.6.3 again would mean that the HP is still roughly at September 2012 (the first release of GHC 7.6.x). Furthermore, I don't fully buy into the argument that we should wait for 7.8 to stabilize: Power users will use something near HEAD, anyway, almost all other users will probably use the HP.
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org javascript:; http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
I know it is difficult but if ghc and haskell-platform could align their schedules better then things might be easier to plan in the future.
Really I would like to see a HP release now *and* one after 7.8.1! :) I think HP beta releases should follow each ghc release and there can be additional point release updates as needed between major ghc releases. The stable HP release would come from the latest stable ghc release. So ideally we could have an updated stable release based on 7.6.3 and an alpha/beta release after 7.8.1 is released. For such pre-releases the binaries do not have to be ready on the release day just a source tarball. RCs with binaries once tested could be promoted to stable releases.
Jens,
are you willing to undertake providing support for all the problems in
current 7.6 on ALL platforms right now?
Are you willing to test the builds on all platforms, and be the person to
help everyone who's hitting issues?
doing an HP release now will push back the release timeline of an HP
version with 7.8 that has full first class support for 10.9 clang quirks +
the win64 fixes that are landing in head this past week, along with a whole
slew of other ecosystem amazing improvements.
I suspect the next HP will be using 7.8.2, because certain final steps of
the windows fixes are slated for that release, though maybe things'll move
up and get fixed in 7.8.1. I could be wrong mind you.
I'm *quite super duper happy* that the next HP will be 7.8.
On Thu, Jan 23, 2014 at 11:04 PM, Jens Petersen
I know it is difficult but if ghc and haskell-platform could align
their schedules better then things might be easier to plan in the future.
Really I would like to see a HP release now *and* one after 7.8.1! :) I think HP beta releases should follow each ghc release and there can be additional point release updates as needed between major ghc releases. The stable HP release would come from the latest stable ghc release. So ideally we could have an updated stable release based on 7.6.3 and an alpha/beta release after 7.8.1 is released. For such pre-releases the binaries do not have to be ready on the release day just a source tarball. RCs with binaries once tested could be promoted to stable releases.
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
A few specific points: 1) 2013.4.0.0 isn't really "ready to be pushed" - there were delays, and then some rolling updates... and some churn. While there is a proposed set of packages... and it does compile... there is still some work on the Mac version (it needs to incorporate my patch script for Mavericks). 2) If we roll out 2013.4.0.0 - that will mean a fair bit of work for all the packagers... and they (and I) won't be up for doing it again for a few months. 3) For the Mac release, I've really shied away from solutions that have people install a second C compiler. While some solutions for Mavericks had people installing gcc from macports or the like, I think we are better served with a solution that works with the default tool chain for the platform. I have no experience with FreeBSD, but I would think similar considerations apply (though at least there, everyone has ports.) 4) Stability in both GHC and the library eco-system seems (perhaps subjectively) more stable to me now than it did three/four years ago. In particular, many of the package maintainers for packages in the platform are already ready for the 7.8 release. Further, several important packages (text, aseon, cabal) work best with newer versions of core packages (which will be in 7.8) and are a bit hacky when working with the core shipped with 7.6. All in all, I'm still seeing this discussion coming down strongly in favor of delaying for 7.8. Further, I believe everyone involved so far is on board with the stability aims of the platform. - Mark
participants (4)
-
Carter Schonwald -
Jens Petersen -
Mark Lentczner -
Sven Panne