GHC 7.8 release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

José Pedro Magalhães
(sorry for re-post, but the first one got rejected from some lists due to
too many recipients)

On Fri, Feb 8, 2013 at 2:28 PM, Simon Marlow <marlowsd at gmail.com> wrote:

>  Does this strike a chord with anyone, or have I got the wrong impression
> and everyone is happy with the pace?
>

I am happy with the pace; I like the "release early, release often"
approach. The HP is not forced to use the
latest GHC, and the GHC download page already clearly directs users to the
HP. Slowing down GHC releases
will slow down adoption of new features, because while installing GHC might
be "harder" than installing the HP,
installing GHC HEAD is harder. My experience is that almost no one, apart
from GHC devs, has HEAD, and
they aren't willing to install it just to play with one new feature. Once a
new compiler version is out, however,
many people are happy to try it, even if it has no accompanying HP.


Cheers,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/67b3e6f8/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
In reply to this post by Simon Marlow-7
On Fri, Feb 08, 2013 at 02:28:20PM +0000, Simon Marlow wrote:
>
> 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!

7.2 was billed as a "technology preview" rather than a regular stable
release. However, it still required just as much effort as a regular
stable release, both for us (we probably spent just as much time trying
to make it bug-free, making builds, making docs, etc) and for the
community (libraries still needed to adjust dependencies etc).

One result of that extra effort was that the 7.4 release got delayed,
and the delay was magnified by pushing it over the Christmas period.

7.6 was released roughly according to the regular yearly release plan
(although the 7.4 delay made the gap between the two shorter).


So in my opinion, 7.2 was a bad idea (but I don't think anyone knew that
before we tried it), and I'd agree that we'd be better sticking to
not-more-than-yearly major releases.

I wouldn't oppose less-than-yearly (e.g. every 18 months) if that makes
life easier for distros, library maintainers, the HP, etc. But I
wouldn't advocate it either; from GHC's point of view, historically
we've always had enough new stuff to justify a new major release after a
year.


Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Johan Tibell-2
In reply to this post by Simon Marlow-7
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/7fb5dc42/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Manuel M T Chakravarty
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.tibell at gmail.com>:

> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130209/96e54d26/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Carter Schonwald
+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" <chak at 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.tibell at gmail.com>:
>
> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/49dfc45b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
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.
Let me suggest once more a possible path, along the lines you suggest

?        For people who value stability: use the Haskell Platform.  Ignore GHC releases.

?        For people who want as many features as possible: use GHC releases.

?        For people who want to live on the bleeding edge: build HEAD from source


The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed.  HP may perfectly sensibly skip an entire release entirely.

In short, I think we already have the situation that you desire.  Perhaps we just need to market it better?

Or am I mistaken?

Simon

From: Carter Schonwald [mailto:carter.schonwald at gmail.com]
Sent: 09 February 2013 02:45
To: Manuel Chakravarty
Cc: GHC Users List; ghc-devs at haskell.org; Andreas Voellmy; Simon Peyton-Jones; Edsko de Vries; Mark Lentczner; Johan Tibell; parallel-haskell
Subject: Re: GHC 7.8 release?


+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" <chak at cse.unsw.edu.au<mailto:chak at 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.tibell at gmail.com<mailto:johan.tibell at gmail.com>>:
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130209/5be27d60/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Marlow-7
In reply to this post by Manuel M T Chakravarty
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.tibell at gmail.com <mailto:johan.tibell at gmail.com>>:
>> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at gmail.com
>> <mailto:marlowsd at 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
>



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
>
> As a straw man, let's suppose we want to do annual API releases in
> September, with intermediate non-API releases in February.

That's a non-API release 5 months after the API release.

6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
 7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
 7.2.2 was 3   months after  7.2.1
 7.4.2 was 4   months after  7.4.1
 7.6.2 was 4.5 months after  7.6.2

so if we do non-API releases, then perhaps it would make sense to stop
doing minor releases (unless a release turns out to just be broken).


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Mark Lentczner-2
We seem to be circling ever closer to consensus here! Yay!

I think the distinction of non-API breaking and API breaking release is
very important. Refining SPJ's trifecta:


*Haskell Platform* comes out twice a year. It is based on very stable
version of GHC, and intention is that people can just assume things on
Hackage work with it. These are named for the year and sequence of the
release: 2013.2, 2013.2.1, 2013.4,...

*Non-API breaking releases* can come out as often as desired. However, the
version that is current as of mid-Feb. and mid-Aug. will be the ones
considered for HP inclusion. By non-API breaking we mean the whole API
surface including all the libraries bundled with GHC, as well as the
operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be
explicitly enabled are okay. Additions of new APIs into existing modules
are discouraged: Much code often imports base modules wholesale, and name
clashes could easily result. These should never bump the major revision
number: 7.4.1, 7.4.2...

*API breaking releases* happen by being released into a separate channel
when ready for library owners to look at them. This channel should probably
go through several stages: Ready for core package owners to work with, then
HP package owners, then all package owners. I'd imagine this is a several
month process. At the end of which, the release can go into the main
channel. Such a merge shouldn't happen more than once a year... I think
even once every two years is fine (!) To avoid confusion, I'd suggest that
while in the separate channel, these release be named with odd number: 7.9,
7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12...


This idea of three channels needs to be much more clearly communicated. The
warning on the download page is a failure: Googling "ghc" takes you to the
home page of GHC which immediately trumpets the "Lastest News" of a release
of GHC 7.6.2. Once a user has read that and decided to download, then
"STOP!" box is a) going to be skipped as they scan for the download link,
and b) if read and followed, causes the "WTF? Why is HP so back rev?" So we
need to change the front page so that the three channels are clearly
communicated and targeted at the right users.

- Mark

(BTW: The first few links on the GHC web site are out of date: The second
nav link is to a survey that is 7 years old. The License page is 8 years
out of date. The FAQ is over a year old.)


On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian at well-typed.com> wrote:

> On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
> >
> > As a straw man, let's suppose we want to do annual API releases in
> > September, with intermediate non-API releases in February.
>
> That's a non-API release 5 months after the API release.
>
> 6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
> 6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
>  7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
>  7.2.2 was 3   months after  7.2.1
>  7.4.2 was 4   months after  7.4.1
>  7.6.2 was 4.5 months after  7.6.2
>
> so if we do non-API releases, then perhaps it would make sense to stop
> doing minor releases (unless a release turns out to just be broken).
>
>
> Thanks
> Ian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130209/4e12abfc/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Manuel M T Chakravarty
In reply to this post by Simon Peyton Jones
Simon Peyton-Jones <simonpj at microsoft.com>:

> 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.
>
> Let me suggest once more a possible path, along the lines you suggest
> ?        For people who value stability: use the Haskell Platform.  Ignore GHC releases.
> ?        For people who want as many features as possible: use GHC releases.
> ?        For people who want to live on the bleeding edge: build HEAD from source
>  
> The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed.  HP may perfectly sensibly skip an entire release entirely.
>  
> In short, I think we already have the situation that you desire.  Perhaps we just need to market it better?
>  
> Or am I mistaken?

There is one kink: for GHC releases to be *useful* substitutes for the HP for people who want medium stability, they must not change (expect maybe add to) the APIs in GHC versions that do not coincide with HP releases.

Why? If they change APIs, many of the packages on Hackage will not build with these intermediate GHC releases, which makes them useless for anything, but testing GHC.

Otherwise, I am perfectly happy with your suggestion. However, this is not the status quo. All (major) GHC releases do break critical packages on Hackage.

Manuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130210/d7711af5/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Manuel M T Chakravarty
In reply to this post by Simon Marlow-7
Simon Marlow <marlowsd at gmail.com>:
> 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?

That sounds sensible to me.

Related to this, then, is the management of branches, which, I think, we can improve in two ways:

(1) Make all library packages into submodules.
(2) Fork-instead-of-branch and use GitHub pull requests.

Re (1): submodules make tracking of synchronised branches across multiple repos simpler. Yes, they also have their pitfalls, but given that we are already using submodules extensively, we need to deal with those pitfalls anyway. So, why not reap the benefits, too?

Re (2): we should encourage contributors to fork the GHC repos on GitHub and work in those. That makes it easy for everybody to build forks (which will be longer-lived under the above policy) and creating a fork doesn't require any special privileges in GHC repos. Finally, we can use GitHub pull requests to track contributions that are pending integration. This is IMHO also much nicer than attaching patches at Trac tickets.

Manuel

> 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.tibell at gmail.com <mailto:johan.tibell at gmail.com>>:
>>> On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <marlowsd at gmail.com
>>> <mailto:marlowsd at 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
>>
>
> --
>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Roman Cheplyaka-2
* Manuel M T Chakravarty <chak at cse.unsw.edu.au> [2013-02-10 21:17:07+1100]
> Re (2): we should encourage contributors to fork the GHC repos on
> GitHub and work in those. That makes it easy for everybody to build
> forks (which will be longer-lived under the above policy) and creating
> a fork doesn't require any special privileges in GHC repos. Finally,
> we can use GitHub pull requests to track contributions that are
> pending integration. This is IMHO also much nicer than attaching
> patches at Trac tickets.

FYI, it is also possible to create pull requests from one branch to
another. So, for people who already have push-access to the main repo
it is not strictly necessary to fork in order to submit a pull request.

Roman


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Mark Lentczner-2
We seem to be circling ever closer to consensus here! Yay!

Indeed!  Good :-)

However, I?m not getting the bit about API changing vs non-API changing.

Firstly I don?t know which APIs are intended.  The GHC API is essentially GHC itself, so it changes daily.  Maybe you mean the base package?  Or what?

I suspect you mean that a ?non-API-changing? release absolutely guarantees to compile any package that compiled with the previous version.  If so, that is a very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles).  But I think it would be difficult to guarantee for anything beyond a patch release.  Every single commit (and the commit rate is many/day) would have to be evaluated against this criterion.  And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we?d have two HEADs.  I can?t see us sustaining this.  And I don?t yet really see why it?s necessary.  If you don?t want an API-breaking change, stick with the patch releases.

So, we have a channel for non-API-breaking changes already: the patch releases.  So that means we already have all three channels!

?        Haskell Platform

?        Patch-level releases

?        New releases

if that?s so, all we need is better signposting.   And I?m all for that!

Have I got this right?

Simon

From: Mark Lentczner [mailto:mark.lentczner at gmail.com]
Sent: 09 February 2013 17:48
To: Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voellmy at gmail.com; Carter Schonwald; kostirya at gmail.com; Edsko de Vries; ghc-devs at haskell.org; glasgow-haskell-users
Subject: Re: GHC 7.8 release?

We seem to be circling ever closer to consensus here! Yay!

I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta:

Haskell Platform comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,...

Non-API breaking releases can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2...

API breaking releases happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion, I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12...

This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling "ghc" takes you to the home page of GHC which immediately trumpets the "Lastest News" of a release of GHC 7.6.2. Once a user has read that and decided to download, then "STOP!" box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the "WTF? Why is HP so back rev?" So we need to change the front page so that the three channels are clearly communicated and targeted at the right users.

- Mark

(BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.)

On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian at well-typed.com<mailto:ian at well-typed.com>> wrote:
On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
>
> As a straw man, let's suppose we want to do annual API releases in
> September, with intermediate non-API releases in February.
That's a non-API release 5 months after the API release.

6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
 7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
 7.2.2 was 3   months after  7.2.1
 7.4.2 was 4   months after  7.4.1
 7.6.2 was 4.5 months after  7.6.2

so if we do non-API releases, then perhaps it would make sense to stop
doing minor releases (unless a release turns out to just be broken).


Thanks
Ian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130210/1fbefb56/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Simon Peyton Jones
, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform.  Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple.

Well our clear intention for point releases (7.6.1 to 7.6.1) is that they should break nothing. I am concerned that in your experience point releases are ?moderately violent?. We go to some pains to make sure that we don?t break anything.    If we don?t succeed on this point-release policy, please do tell us when the release candidate comes out.  If we don?t know we are causing pain, we can?t stop inflicting it :-)

(Major releases are another matter.  There, things are likely to break.)

Simon

From: Brandon Allbery [mailto:allbery.b at gmail.com]
Sent: 09 February 2013 13:41
To: Simon Peyton-Jones
Cc: Carter Schonwald; Manuel Chakravarty; parallel-haskell; Mark Lentczner; GHC Users List; ghc-devs at haskell.org; Edsko de Vries
Subject: Re: GHC 7.8 release?

On Sat, Feb 9, 2013 at 6:27 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
In short, I think we already have the situation that you desire.  Perhaps we just need to market it better?

Or am I mistaken?

Except the current question is about how ghc releases interact with the Platform; this thread was set off by a question about getting 7.6.2 into the next Platform....

And the main issue there is that ghc releases tend to break things and need a lot of testing in general to make it into the Platform; while this would be expected anyway, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform.  Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com<mailto:allbery.b at gmail.com>                                  ballbery at sinenomine.net<mailto:ballbery at sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130210/aa67b8e3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Marlow-7
In reply to this post by Simon Peyton Jones
On 10/02/13 15:36, Simon Peyton-Jones wrote:

> We seem to be circling ever closer to consensus here! Yay!
>
> Indeed!  Good :-)
>
> However, I?m not getting the bit about API changing vs non-API changing.
>
> Firstly I don?t know which APIs are intended.  The GHC API is
> essentially GHC itself, so it changes daily.  Maybe you mean the base
> package?  Or what?
>
> I suspect you mean that a ?non-API-changing? release absolutely
> guarantees to compile any package that compiled with the previous
> version.  If so, that is a very strong constraint indeed. We do observe
> it for patch releases for GHC (e g 7.6.2 should compile anything that
> 7.6.1 compiles).  But I think it would be difficult to guarantee for
> anything beyond a patch release.  Every single commit (and the commit
> rate is many/day) would have to be evaluated against this criterion.
> And if it failed the criterion, it would have to go on a API-breaking
> HEAD. In effect we?d have two HEADs.  I can?t see us sustaining this.
> And I don?t yet really see why it?s necessary.  If you don?t want an
> API-breaking change, stick with the patch releases.
>
> So, we have a channel for non-API-breaking changes already: the patch
> releases.  So that means we already have all three channels!

Mark is asking for major GHC releases every year at the most, preferably
less frequently.  That means major GHC releases in the sense that we do
them now, where libraries change, and a wave of package updates are
required to get everything working.

Johan, Manuel and Carter are saying that they want releases that add
features but don't break code, i.e. a non-API-breaking release, as a way
to get the new bits into the hands of the punters sooner.  This is
something that we don't do right now, and it would entail a change to
our workflow and release schedule.

It doesn't mean no API changes at all - we would have to allow APIs to
be extended, because many feature additions come with new primops, or
new supporting code in the ghc-prim or base packages.  The package
version policy states precisely what it means to extend an API
(http://www.haskell.org/haskellwiki/Package_versioning_policy) and most
third-party packages will still work so long as we only bump the minor
versions of the packages that come with GHC.

The GHC package itself would have to be exempt, because it contains
every module in GHC, and hence would be impossible to keep stable if we
are modifying the compiler to add new features.

Of course it's not practical to maintain an extra branch of GHC for
non-API-breaking development - two branches is already plenty.  So there
would need to be an API-freeze for a while between the major release and
the non-API-breaking release, during which time people developing API
changes would need to work on branches.

Is it workable?  I'm not sure, but I think it's worth a try.  I wouldn't
want to see this replace the patchlevel bugfix releases that we already
do, and as Ian points out, there isn't a lot of room in the release
schedule for more releases, unless we stretch out the timescales, doing
major releases less frequently.

Cheers,
        Simon


> ?Haskell Platform
>
> ?Patch-level releases
>
> ?New releases
>
>
> if that?s so, all we need is better signposting.   And I?m all for that!
>
> Have I got this right?
>
>
> Simon
>
> *From:*Mark Lentczner [mailto:mark.lentczner at gmail.com]
> *Sent:* 09 February 2013 17:48
> *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
> Peyton-Jones; Mark Lentczner; andreas.voellmy at gmail.com; Carter
> Schonwald; kostirya at gmail.com; Edsko de Vries; ghc-devs at haskell.org;
> glasgow-haskell-users
> *Subject:* Re: GHC 7.8 release?
>
> We seem to be circling ever closer to consensus here! Yay!
>
> I think the distinction of non-API breaking and API breaking release is
> very important. Refining SPJ's trifecta:
>
>     *Haskell Platform* comes out twice a year. It is based on very
>     stable version of GHC, and intention is that people can just assume
>     things on Hackage work with it. These are named for the year and
>     sequence of the release: 2013.2, 2013.2.1, 2013.4,...
>
>     *Non-API breaking releases* can come out as often as desired.
>     However, the version that is current as of mid-Feb. and mid-Aug.
>     will be the ones considered for HP inclusion. By non-API breaking we
>     mean the whole API surface including all the libraries bundled with
>     GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions
>     of features that must be explicitly enabled are okay. Additions of
>     new APIs into existing modules are discouraged: Much code often
>     imports base modules wholesale, and name clashes could easily
>     result. These should never bump the major revision number: 7.4.1,
>     7.4.2...
>
>     *API breaking releases* happen by being released into a separate
>     channel when ready for library owners to look at them. This channel
>     should probably go through several stages: Ready for core package
>     owners to work with, then HP package owners, then all package
>     owners. I'd imagine this is a several month process. At the end of
>     which, the release can go into the main channel. Such a merge
>     shouldn't happen more than once a year... I think even once every
>     two years is fine (!) To avoid confusion, I'd suggest that while in
>     the separate channel, these release be named with odd number: 7.9,
>     7.11,..., and when moved to the main channel renamed to even: 7.10,
>     7.12...
>
> This idea of three channels needs to be much more clearly communicated.
> The warning on the download page is a failure: Googling "ghc" takes you
> to the home page of GHC which immediately trumpets the "Lastest News" of
> a release of GHC 7.6.2. Once a user has read that and decided to
> download, then "STOP!" box is a) going to be skipped as they scan for
> the download link, and b) if read and followed, causes the "WTF? Why is
> HP so back rev?" So we need to change the front page so that the three
> channels are clearly communicated and targeted at the right users.
>
> - Mark
>
> (BTW: The first few links on the GHC web site are out of date: The
> second nav link is to a survey that is 7 years old. The License page is
> 8 years out of date. The FAQ is over a year old.)
>
> On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian at well-typed.com
> <mailto:ian at well-typed.com>> wrote:
>
> On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
>  >
>  > As a straw man, let's suppose we want to do annual API releases in
>  > September, with intermediate non-API releases in February.
>
> That's a non-API release 5 months after the API release.
>
> 6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
> 6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
>   7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
>   7.2.2 was 3   months after  7.2.1
>   7.4.2 was 4   months after  7.4.1
>   7.6.2 was 4.5 months after  7.6.2
>
> so if we do non-API releases, then perhaps it would make sense to stop
> doing minor releases (unless a release turns out to just be broken).
>
>
> Thanks
> Ian
>



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
What I am still missing is this:

|  Mark is asking for major GHC releases every year at the most, preferably
|  less frequently.  That means major GHC releases in the sense that we do
|  them now, where libraries change, and a wave of package updates are
|  required to get everything working.

What causes the "wave of package updates"?  Just because GHC 7.8 (say) comes out, no package author need lift a finger.  The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates.  Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP.  

But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately.

You may ask what use is a GHC release that doesn't cause a wave of updates?  And hence that doesn't work with at least some libraries.  Well, it's a very useful forcing function to get new features actually out and tested.   Of course we could just not do that, and say "build from source", but a release brings a welcome discipline.  But under this story, release or not-release would be a Little Deal, not a Big Deal.  The benefits are modest; the costs are modest.

In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting.
       
Simon

|  
|  Johan, Manuel and Carter are saying that they want releases that add
|  features but don't break code, i.e. a non-API-breaking release, as a way
|  to get the new bits into the hands of the punters sooner.  This is
|  something that we don't do right now, and it would entail a change to
|  our workflow and release schedule.
|  
|  It doesn't mean no API changes at all - we would have to allow APIs to
|  be extended, because many feature additions come with new primops, or
|  new supporting code in the ghc-prim or base packages.  The package
|  version policy states precisely what it means to extend an API
|  (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most
|  third-party packages will still work so long as we only bump the minor
|  versions of the packages that come with GHC.
|  
|  The GHC package itself would have to be exempt, because it contains
|  every module in GHC, and hence would be impossible to keep stable if we
|  are modifying the compiler to add new features.
|  
|  Of course it's not practical to maintain an extra branch of GHC for
|  non-API-breaking development - two branches is already plenty.  So there
|  would need to be an API-freeze for a while between the major release and
|  the non-API-breaking release, during which time people developing API
|  changes would need to work on branches.
|  
|  Is it workable?  I'm not sure, but I think it's worth a try.  I wouldn't
|  want to see this replace the patchlevel bugfix releases that we already
|  do, and as Ian points out, there isn't a lot of room in the release
|  schedule for more releases, unless we stretch out the timescales, doing
|  major releases less frequently.
|  
|  Cheers,
|   Simon
|  
|  
|  > ?Haskell Platform
|  >
|  > ?Patch-level releases
|  >
|  > ?New releases
|  >
|  >
|  > if that?s so, all we need is better signposting.   And I?m all for that!
|  >
|  > Have I got this right?
|  >
|  >
|  > Simon
|  >
|  > *From:*Mark Lentczner [mailto:mark.lentczner at gmail.com]
|  > *Sent:* 09 February 2013 17:48
|  > *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
|  > Peyton-Jones; Mark Lentczner; andreas.voellmy at gmail.com; Carter
|  > Schonwald; kostirya at gmail.com; Edsko de Vries; ghc-devs at haskell.org;
|  > glasgow-haskell-users
|  > *Subject:* Re: GHC 7.8 release?
|  >
|  > We seem to be circling ever closer to consensus here! Yay!
|  >
|  > I think the distinction of non-API breaking and API breaking release is
|  > very important. Refining SPJ's trifecta:
|  >
|  >     *Haskell Platform* comes out twice a year. It is based on very
|  >     stable version of GHC, and intention is that people can just assume
|  >     things on Hackage work with it. These are named for the year and
|  >     sequence of the release: 2013.2, 2013.2.1, 2013.4,...
|  >
|  >     *Non-API breaking releases* can come out as often as desired.
|  >     However, the version that is current as of mid-Feb. and mid-Aug.
|  >     will be the ones considered for HP inclusion. By non-API breaking we
|  >     mean the whole API surface including all the libraries bundled with
|  >     GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions
|  >     of features that must be explicitly enabled are okay. Additions of
|  >     new APIs into existing modules are discouraged: Much code often
|  >     imports base modules wholesale, and name clashes could easily
|  >     result. These should never bump the major revision number: 7.4.1,
|  >     7.4.2...
|  >
|  >     *API breaking releases* happen by being released into a separate
|  >     channel when ready for library owners to look at them. This channel
|  >     should probably go through several stages: Ready for core package
|  >     owners to work with, then HP package owners, then all package
|  >     owners. I'd imagine this is a several month process. At the end of
|  >     which, the release can go into the main channel. Such a merge
|  >     shouldn't happen more than once a year... I think even once every
|  >     two years is fine (!) To avoid confusion, I'd suggest that while in
|  >     the separate channel, these release be named with odd number: 7.9,
|  >     7.11,..., and when moved to the main channel renamed to even: 7.10,
|  >     7.12...
|  >
|  > This idea of three channels needs to be much more clearly communicated.
|  > The warning on the download page is a failure: Googling "ghc" takes you
|  > to the home page of GHC which immediately trumpets the "Lastest News" of
|  > a release of GHC 7.6.2. Once a user has read that and decided to
|  > download, then "STOP!" box is a) going to be skipped as they scan for
|  > the download link, and b) if read and followed, causes the "WTF? Why is
|  > HP so back rev?" So we need to change the front page so that the three
|  > channels are clearly communicated and targeted at the right users.
|  >
|  > - Mark
|  >
|  > (BTW: The first few links on the GHC web site are out of date: The
|  > second nav link is to a survey that is 7 years old. The License page is
|  > 8 years out of date. The FAQ is over a year old.)
|  >
|  > On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian at well-typed.com
|  > <mailto:ian at well-typed.com>> wrote:
|  >
|  > On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
|  >  >
|  >  > As a straw man, let's suppose we want to do annual API releases in
|  >  > September, with intermediate non-API releases in February.
|  >
|  > That's a non-API release 5 months after the API release.
|  >
|  > 6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
|  > 6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
|  >   7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
|  >   7.2.2 was 3   months after  7.2.1
|  >   7.4.2 was 4   months after  7.4.1
|  >   7.6.2 was 4.5 months after  7.6.2
|  >
|  > so if we do non-API releases, then perhaps it would make sense to stop
|  > doing minor releases (unless a release turns out to just be broken).
|  >
|  >
|  > Thanks
|  > Ian
|  >


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:
>
> You may ask what use is a GHC release that doesn't cause a wave of updates?  And hence that doesn't work with at least some libraries.  Well, it's a very useful forcing function to get new features actually out and tested.

But the way you test new features is to write programs that use them,
and programs depend on libraries.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

David Terei
In reply to this post by Simon Peyton Jones
On 10 February 2013 13:02, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> What I am still missing is this:
>
> |  Mark is asking for major GHC releases every year at the most, preferably
> |  less frequently.  That means major GHC releases in the sense that we do
> |  them now, where libraries change, and a wave of package updates are
> |  required to get everything working.
>
> What causes the "wave of package updates"?  Just because GHC 7.8 (say) comes out, no package author need lift a finger.  The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates.  Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP.
>
> But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately.
>
> You may ask what use is a GHC release that doesn't cause a wave of updates?  And hence that doesn't work with at least some libraries.  Well, it's a very useful forcing function to get new features actually out and tested.   Of course we could just not do that, and say "build from source", but a release brings a welcome discipline.  But under this story, release or not-release would be a Little Deal, not a Big Deal.  The benefits are modest; the costs are modest.
>
> In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting.

My understanding of the proposed changes (which I'm also supportive
of) is to separate GHC improvements that break existing libraries (or
perhaps even simply add language level features), and those that are
improvements under-the-hood (e.g., bug fixes, performance
improvements).

So rather than 7.8 be a huge single release containing new type level
features, SIMD, the new code-generator. There would be two releases,
one containing just say the new-code-generator, improvements to the IO
manager, potentially also DPH... another release would containing new
language level improvements.

So then HP can benefit from improvements to the existing language and
API without having to also pull in breaking (or just extending)
changes...

It's the issue of a research compiler Vs. and industrial compiler and
managing that more explicitly in the release model.

Cheers,
David

>
> Simon
>
> |
> |  Johan, Manuel and Carter are saying that they want releases that add
> |  features but don't break code, i.e. a non-API-breaking release, as a way
> |  to get the new bits into the hands of the punters sooner.  This is
> |  something that we don't do right now, and it would entail a change to
> |  our workflow and release schedule.
> |
> |  It doesn't mean no API changes at all - we would have to allow APIs to
> |  be extended, because many feature additions come with new primops, or
> |  new supporting code in the ghc-prim or base packages.  The package
> |  version policy states precisely what it means to extend an API
> |  (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most
> |  third-party packages will still work so long as we only bump the minor
> |  versions of the packages that come with GHC.
> |
> |  The GHC package itself would have to be exempt, because it contains
> |  every module in GHC, and hence would be impossible to keep stable if we
> |  are modifying the compiler to add new features.
> |
> |  Of course it's not practical to maintain an extra branch of GHC for
> |  non-API-breaking development - two branches is already plenty.  So there
> |  would need to be an API-freeze for a while between the major release and
> |  the non-API-breaking release, during which time people developing API
> |  changes would need to work on branches.
> |
> |  Is it workable?  I'm not sure, but I think it's worth a try.  I wouldn't
> |  want to see this replace the patchlevel bugfix releases that we already
> |  do, and as Ian points out, there isn't a lot of room in the release
> |  schedule for more releases, unless we stretch out the timescales, doing
> |  major releases less frequently.
> |
> |  Cheers,
> |       Simon
> |
> |
> |  > ?Haskell Platform
> |  >
> |  > ?Patch-level releases
> |  >
> |  > ?New releases
> |  >
> |  >
> |  > if that?s so, all we need is better signposting.   And I?m all for that!
> |  >
> |  > Have I got this right?
> |  >
> |  >
> |  > Simon
> |  >
> |  > *From:*Mark Lentczner [mailto:mark.lentczner at gmail.com]
> |  > *Sent:* 09 February 2013 17:48
> |  > *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
> |  > Peyton-Jones; Mark Lentczner; andreas.voellmy at gmail.com; Carter
> |  > Schonwald; kostirya at gmail.com; Edsko de Vries; ghc-devs at haskell.org;
> |  > glasgow-haskell-users
> |  > *Subject:* Re: GHC 7.8 release?
> |  >
> |  > We seem to be circling ever closer to consensus here! Yay!
> |  >
> |  > I think the distinction of non-API breaking and API breaking release is
> |  > very important. Refining SPJ's trifecta:
> |  >
> |  >     *Haskell Platform* comes out twice a year. It is based on very
> |  >     stable version of GHC, and intention is that people can just assume
> |  >     things on Hackage work with it. These are named for the year and
> |  >     sequence of the release: 2013.2, 2013.2.1, 2013.4,...
> |  >
> |  >     *Non-API breaking releases* can come out as often as desired.
> |  >     However, the version that is current as of mid-Feb. and mid-Aug.
> |  >     will be the ones considered for HP inclusion. By non-API breaking we
> |  >     mean the whole API surface including all the libraries bundled with
> |  >     GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions
> |  >     of features that must be explicitly enabled are okay. Additions of
> |  >     new APIs into existing modules are discouraged: Much code often
> |  >     imports base modules wholesale, and name clashes could easily
> |  >     result. These should never bump the major revision number: 7.4.1,
> |  >     7.4.2...
> |  >
> |  >     *API breaking releases* happen by being released into a separate
> |  >     channel when ready for library owners to look at them. This channel
> |  >     should probably go through several stages: Ready for core package
> |  >     owners to work with, then HP package owners, then all package
> |  >     owners. I'd imagine this is a several month process. At the end of
> |  >     which, the release can go into the main channel. Such a merge
> |  >     shouldn't happen more than once a year... I think even once every
> |  >     two years is fine (!) To avoid confusion, I'd suggest that while in
> |  >     the separate channel, these release be named with odd number: 7.9,
> |  >     7.11,..., and when moved to the main channel renamed to even: 7.10,
> |  >     7.12...
> |  >
> |  > This idea of three channels needs to be much more clearly communicated.
> |  > The warning on the download page is a failure: Googling "ghc" takes you
> |  > to the home page of GHC which immediately trumpets the "Lastest News" of
> |  > a release of GHC 7.6.2. Once a user has read that and decided to
> |  > download, then "STOP!" box is a) going to be skipped as they scan for
> |  > the download link, and b) if read and followed, causes the "WTF? Why is
> |  > HP so back rev?" So we need to change the front page so that the three
> |  > channels are clearly communicated and targeted at the right users.
> |  >
> |  > - Mark
> |  >
> |  > (BTW: The first few links on the GHC web site are out of date: The
> |  > second nav link is to a survey that is 7 years old. The License page is
> |  > 8 years out of date. The FAQ is over a year old.)
> |  >
> |  > On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian at well-typed.com
> |  > <mailto:ian at well-typed.com>> wrote:
> |  >
> |  > On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
> |  >  >
> |  >  > As a straw man, let's suppose we want to do annual API releases in
> |  >  > September, with intermediate non-API releases in February.
> |  >
> |  > That's a non-API release 5 months after the API release.
> |  >
> |  > 6.10.2 was 5   months after 6.10.1 (.3 was 1 month later, .4 a further 2)
> |  > 6.12.2 was 4   months after 6.12.1 (.3 was 2 months later)
> |  >   7.0.2 was 3.5 months after  7.0.1 (.3 was 1 month later, .4 a further 3)
> |  >   7.2.2 was 3   months after  7.2.1
> |  >   7.4.2 was 4   months after  7.4.1
> |  >   7.6.2 was 4.5 months after  7.6.2
> |  >
> |  > so if we do non-API releases, then perhaps it would make sense to stop
> |  > doing minor releases (unless a release turns out to just be broken).
> |  >
> |  >
> |  > Thanks
> |  > Ian
> |  >
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Ian Lynagh-2
|  > You may ask what use is a GHC release that doesn't cause a wave of updates?
|  And hence that doesn't work with at least some libraries.  Well, it's a very useful
|  forcing function to get new features actually out and tested.
|  
|  But the way you test new features is to write programs that use them,
|  and programs depend on libraries.

That is of course ideal, but the ideal carries costs.  A half way house is a release whose library support will be patchy.  Not such good testing, but much lower costs.  But still (I think) a lot more testing than "compile HEAD" gives us.

Simon


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
On Sun, Feb 10, 2013 at 09:30:23PM +0000, Simon Peyton-Jones wrote:
> |  > You may ask what use is a GHC release that doesn't cause a wave of updates?
> |  And hence that doesn't work with at least some libraries.  Well, it's a very useful
> |  forcing function to get new features actually out and tested.
> |  
> |  But the way you test new features is to write programs that use them,
> |  and programs depend on libraries.
>
> That is of course ideal, but the ideal carries costs.  A half way house is a release whose library support will be patchy.

But that's not what happens. GHC 7.8 is released. Someone installs it in
order to try to use TypeHoles when developing their program. But their
program depends on text, so they send Bryan a mail saying that text
doesn't build with 7.8. And so the wave of updates begins.


Thanks
Ian



1234