+10^100 to Johan and Manuel. Breaking changes on pieces that aren't experimental is the main compatibility / new version pain,
and I say this as someone who's spent time before and around the 7.4 and 7.6 releases testing out lots of major packages and sending a few patches to various maintainers. If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. -Carter On Feb 8, 2013 9:05 PM, "Manuel M T Chakravarty" <c...@cse.unsw.edu.au> wrote: > 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