I agree too - I think it would be great to have non-API-breaking
releases with new features. So let's think about how that could work.
Some features add APIs, e.g. SIMD adds new primops. So we have to
define non-API-breaking as a minor version bump in the PVP sense; that
is, you can add to an API but not change it.
As a straw man, let's suppose we want to do annual API releases in
September, with intermediate non-API releases in February. Both would
be classed as "major", and bump the GHC major version, but the Feb
releases would only be allowed to bump minor versions of packages.
(except perhaps the version of the GHC package, which is impossible to
keep stable if we change the compiler).
So how to manage the repos. We could have three branches, but that
doesn't seem practical. Probably the best way forward is to develop new
features on separate branches and merge them into master at the
appropriate time - i.e. API-breaking feature branches could only be
merged in after the Feb release.
Thoughts?
Cheers,
Simon
On 09/02/13 02:04, Manuel M T Chakravarty 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 <mailto:johan.tib...@gmail.com>>:
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlo...@gmail.com
<mailto: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
