I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages.
I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell <johan.tib...@gmail.com>: > On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlo...@gmail.com> wrote: > For a while we've been doing one major release per year, and 1-2 minor > releases. We have a big sign at the top of the download page directing > people to the platform. We arrived here after various discussions in the > past - there were always a group of people that wanted stability, and a > roughly equally vocal group of people who wanted the latest bits. So we > settled on one API-breaking change per year as a compromise. > > Since then, the number of packages has ballooned, and there's a new factor in > the equation: the cost to the ecosystem of an API-breaking release of GHC. > All that updating of packages collectively costs the community a lot of time, > for little benefit. Lots of package updates contributes to Cabal Hell. The > package updates need to happen before the platform picks up the GHC release, > so that when it goes into the platform, the packages are ready. > > So I think, if anything, there's pressure to have fewer major releases of > GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 > was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making > releases! > > I think we want to decouple GHC "major" releases (as in, we did lots of work) > from API breaking releases. For example, GCC has lots of major (or "big") > releases, but rarely, if ever, break programs. > > I'd be delighted to see a release once in a while that made my programs > faster/smaller/buggy without breaking any of them. > > -- Johan
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
