GHC 7.8 release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
142 messages Options
123456 ... 8
Reply | Threaded
Open this post in threaded view
|

RE: 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:[hidden email]]
|  > *Sent:* 09 February 2013 17:48
|  > *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
|  > Peyton-Jones; Mark Lentczner; [hidden email]; Carter
|  > Schonwald; [hidden email]; Edsko de Vries; [hidden email];
|  > 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 <[hidden email]
|  > <mailto:[hidden email]>> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

David Terei
In reply to this post by Simon Peyton Jones
On 10 February 2013 13:02, Simon Peyton-Jones <[hidden email]> 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:[hidden email]]
> |  > *Sent:* 09 February 2013 17:48
> |  > *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
> |  > Peyton-Jones; Mark Lentczner; [hidden email]; Carter
> |  > Schonwald; [hidden email]; Edsko de Vries; [hidden email];
> |  > 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 <[hidden email]
> |  > <mailto:[hidden email]>> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Ganesh Sittampalam
On 10/02/2013 21:43, Ian Lynagh wrote:

> 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.

As the maintainer of a low-level package (HTTP), I certainly see this
kind of pressure starting even before a GHC release - e.g.
https://github.com/haskell/HTTP/issues/36

As one of the maintainers of a high-level tool (darcs) that aims to
always build against the current HP, I generate this kind of pressure
myself: once GHC is released, I expect it to be in the HP within 3-6
months, so I need to get started quickly. I can't even check darcs
itself until the dependencies work.

I don't think there are any easy answers :-/

Ganesh


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Carter Schonwald
In reply to this post by Ian Lynagh-2

Yes, exactly this.

A release where the versions of base, and all other baked in libraries are only minor version bumps and where breaking changes are localized to relatively experimental language features / extensions and GHC specific APIs would ideal. 

Eg: I'm OK having to patch ghc-mod so it works with a new intermediate GHC release.  (Esp since it uses GHC internal apis)

The new scheduler improvements, the recent doh work  , the great SIMD work / code generator improvments, the type level nats, ordered type families,  the overloaded list syntax,

All of these extensions and associated API augmentations should not break stable libraries, at least on minor version bumps, cause
1) maybe experimental new APIs can be included in minor releases as separate explicitly experimental modules (this gives a way of including new functionality in a minor release)
2) generally type checking / inference on stable code that doesn't enable new features stays the same.

I'm probably overlooking some pieces or. Details, and I'm largely restating what Johan and Manuel have communicated.

-Carter

On Feb 10, 2013 4:43 PM, "Ian Lynagh" <[hidden email]> wrote:
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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Gabriel Dos Reis
In reply to this post by Ian Lynagh-2
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <[hidden email]> wrote:

> 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

Releasing GHC early and often (possibly with API breakage) isn't
really the problem.  The real problem is how to coordinate with
library authors (e.g. Haskell Platform), etc.

I suspect GHC should continue to offer a platform for research
and experiments. That is much harder if you curtail the ability to
release GHC early and often.

-- Gaby

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Carter Schonwald

Well said. Having a more aggressive release cycle is another interesting perspective.

On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <[hidden email]> wrote:
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <[hidden email]> wrote:
> 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

Releasing GHC early and often (possibly with API breakage) isn't
really the problem.  The real problem is how to coordinate with
library authors (e.g. Haskell Platform), etc.

I suspect GHC should continue to offer a platform for research
and experiments. That is much harder if you curtail the ability to
release GHC early and often.

-- Gaby

_______________________________________________
ghc-devs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Brandon Allbery
In reply to this post by Simon Peyton Jones
On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <[hidden email]> wrote:
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.

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason.  It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

John Lato-2
In reply to this post by Carter Schonwald
While I'm notionally in favor of decoupling API-breaking changes from non-API breaking changes, there are two major difficulties: GHC.Prim and Template Haskell. Should a non-API-breaking change mean that GHC.Prim is immutable?  If so, this greatly restricts GHC's development.  If not, it means that a large chunk of hackage will become unbuildable due to deps on vector and primitive.  With Template Haskell the situation is largely similar, although the deps are different.

What I would like to see are more patch-level bugfix releases.  I suspect the reason we don't have more is that making a release is a lot of work.  So, Ian, what needs to happen to make more frequent patch releases feasible?



On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald <[hidden email]> wrote:

Well said. Having a more aggressive release cycle is another interesting perspective.

On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <[hidden email]> wrote:
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <[hidden email]> wrote:
> 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

Releasing GHC early and often (possibly with API breakage) isn't
really the problem.  The real problem is how to coordinate with
library authors (e.g. Haskell Platform), etc.

I suspect GHC should continue to offer a platform for research
and experiments. That is much harder if you curtail the ability to
release GHC early and often.

-- Gaby

_______________________________________________
ghc-devs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ghc-devs



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Joachim Breitner-2
In reply to this post by Carter Schonwald
Hi,

one remedy to the problem could be better infrastructure:
      * More automated test-building of packages on hackage (including
        test suites) with various GHC releases, and better display of
        the results. This way, library authors would not have to
        manually build their library to see if they work with the latest
        compiler.
      * Automatic test building of packages with explicit relaxation of
        the dependencies, to suggest dependency relaxation that would
        work without code changes (from my work at Debian, in most cases
        only meta-data changes are required to support newer versions of
        dependencies, including core libs).
      * A more liberal attitude to changing other peoples packages’s
        metadata to fix the dependencies – either to exclude broken
        combinations or to expand the range. Preferably online, similar
        to the edit button in github, and checked by the above CI
        infrastructure.

This way, it would be easier for libraries to support newer GHC releases
without having to give up supporting older releases.

But I know that development of Hackage is not something that seems to be
happening a lot right now, and as I don’t help, I’m not complaining. So
consider this a side notice and carry on discussing :-)

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Gabriel Dos Reis
On Mon, Feb 11, 2013 at 2:46 AM, Joachim Breitner
<[hidden email]> wrote:

> Hi,
>
> one remedy to the problem could be better infrastructure:
>       * More automated test-building of packages on hackage (including
>         test suites) with various GHC releases, and better display of
>         the results. This way, library authors would not have to
>         manually build their library to see if they work with the latest
>         compiler.
>       * Automatic test building of packages with explicit relaxation of
>         the dependencies, to suggest dependency relaxation that would
>         work without code changes (from my work at Debian, in most cases
>         only meta-data changes are required to support newer versions of
>         dependencies, including core libs).
>       * A more liberal attitude to changing other peoples packages’s
>         metadata to fix the dependencies – either to exclude broken
>         combinations or to expand the range. Preferably online, similar
>         to the edit button in github, and checked by the above CI
>         infrastructure.
>
> This way, it would be easier for libraries to support newer GHC releases
> without having to give up supporting older releases.
>
> But I know that development of Hackage is not something that seems to be
> happening a lot right now, and as I don’t help, I’m not complaining. So
> consider this a side notice and carry on discussing :-)
>
> Greetings,
> Joachim

The issue is largely "social" problem that I suspect technological
solutions won't solve.  Yes, it would be nice to have better
infrastructure.  However, at the end of the day, when the automated
tests say an API or ABI set has been broken, a non-technical
decision needs to be taken (should it be part of the next release, or
should it be delayed or removed?)  And you will be back to square one.

Part of the problem is what happens to successful
programming languages: you get users, and users -- believe it or not --
like stability (few people like fiddling with function names and
arguments in an otherwise working program or library) and, yes they
will take new improvements as long as their working programs continue
working.  Researchers on the other hand need room to experiment with
ideas; they need to get their implementations in the wild to get a sense
of what scales, what doesn't.  These facts are in tension; you can't
solve it by more automated testing.

If you want GHC to compete with GCC or Clang, then you know what
to do: stop experimenting with the language.   So far, most of the work
on GHC has been done by researchers who are not paid to
do "development work" -- unless academia changes its standards...

-- Gaby

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Ian Lynagh-2
In reply to this post by John Lato-2
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote:
>
> What I would like to see are more patch-level bugfix releases.  I suspect
> the reason we don't have more is that making a release is a lot of work.
>  So, Ian, what needs to happen to make more frequent patch releases
> feasible?

Well,
* actually making a release takes time
* I assume that you also want more patches merged from the HEAD, rather
  than just putting intermediate releases out, in which case merging
  those patches also takes time. And most of the small fixes already get
  merged, so you'd be looking at merging bigger changes which are more
  likely to require resolving conflicts, and so take even more time

so basically to make more releases we'd need to spend less time doing
other stuff (or for someone else to look after the branch).

Bigger changes, and especially changes that need altering for the stable
branch, are also more likely to introduce bugs.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Gabriel Dos Reis
In reply to this post by Simon Peyton Jones
On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones
<[hidden email]> 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.  Not such good testing, but much lower costs.  But still (I think) a lot more testing than "compile HEAD" gives us.
>
> Simon

Fitting:

     http://xkcd.com/1172/

(sorry, I couldn't resist)

-- Gaby

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Brandon Allbery

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

                                         

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

 

These must be social questions (what I was earlier calling “signposting”) rather than technical ones.  For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it?  They don’t openly insult anyone who points to a release just because HEAD has new cool stuff!  No, they track things we call “releases”.  Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP.

 

Or something.   I’m just looking for a way to reconcile

·        Release early, release often

·        Stability for the Haskell Platform

It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now.  But maybe I’m wrong.

 

Simon

 

From: Brandon Allbery [mailto:[hidden email]]
Sent: 11 February 2013 01:15
To: Simon Peyton-Jones
Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; [hidden email]; glasgow-haskell-users; [hidden email]; Edsko de Vries
Subject: Re: GHC 7.8 release?

 

On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <[hidden email]> wrote:

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.

 

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

                                                   

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

 

You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason.  It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users.

 

--

brandon s allbery kf8nh                               sine nomine associates

[hidden email]                                  [hidden email]

unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Joachim Breitner-2
Hi,

Am Montag, den 11.02.2013, 22:31 +0000 schrieb Simon Peyton-Jones:
> No, they track things we call “releases”.  Very well, maybe we should
> call them “previews” instead, and only dignify it as a “release” when,
> and only when a preview is picked by HP as worthy of incorporation in
> the next HP.

wording does indeed help a lot. I remember that 7.2 was dubbed a
technology review with the effect that, at least Debian, never included
it in the main repository. It was packaged and provided in experimental,
for easy access to those who want to play with it, but not with
additional library packages. From what I can remember, there was no push
towards supporting 7.2 properly, and I believe this would have been
different if 7.2 was just “the next regular GHC release”.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Carter Schonwald
In reply to this post by Simon Peyton Jones
Agreed.

having relatively bug free "technology preview" releases, which (perhaps ideally) have new functionality included in a way that keeps the breakage overhead lowish, on a regular basis, is ideal.

one thought on the api hacking front:

the main concern we're hitting is that we want to not "pin" internal GHC apis, yet we want to make the breakage rate on libraries people may want to use that might depend on say GHC.Prim or GHC.TH to be minimal.

Is a possible solution that on preview releases we have the changed bits of API for a module M to be exported in a module M.Experimental?

eg, new ghc primops  in a tech preview release maybe are exported by GHC.Prim.Experimental
(or something of this sort?)

just throwing out one possible point in the design space.

cheers
-Carter



On Mon, Feb 11, 2013 at 5:31 PM, Simon Peyton-Jones <[hidden email]> wrote:

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

                                         

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

 

These must be social questions (what I was earlier calling “signposting”) rather than technical ones.  For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it?  They don’t openly insult anyone who points to a release just because HEAD has new cool stuff!  No, they track things we call “releases”.  Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP.

 

Or something.   I’m just looking for a way to reconcile

·        Release early, release often

·        Stability for the Haskell Platform

It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now.  But maybe I’m wrong.

 

Simon

 

From: Brandon Allbery [mailto:[hidden email]]
Sent: 11 February 2013 01:15
To: Simon Peyton-Jones
Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; [hidden email]; glasgow-haskell-users; [hidden email]; Edsko de Vries


Subject: Re: GHC 7.8 release?

 

On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <[hidden email]> wrote:

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.

 

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

                                                   

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

 

You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason.  It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users.

 

--

brandon s allbery kf8nh                               sine nomine associates

[hidden email]                                  [hidden email]

unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
ghc-devs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/ghc-devs



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

Johan Tibell-2
Hi,

I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at  compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff?

-- Johan

* A major GCC release usually signifies that some large change to the code generator was made.



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC 7.8 release?

kudah
On Mon, 11 Feb 2013 15:03:25 -0800 Johan Tibell
<[hidden email]> wrote:

> Many platforms (e.g. Java and Python) rarely, if ever,
> make breaking changes. If you look at compiler projects (e.g. LLVM
> and GCC) you never see intentional breakages, even in major
> releases*.

Those are very mature platforms, hundreds of millions of people
use them indirectly each day, it's hard to compare GHC to them.
If anything, Haskell is very young for its age, and should rather move
faster. Bad mistakes, accidents and partial or inefficient
implementations proliferate in standard libraries for decades,
tampering GHC's growth as a serious production language.

On Mon, 11 Feb 2013 22:31:53 +0000 Simon Peyton-Jones
<[hidden email]> wrote:

> no linux distribution tracks HEAD, does it?

Gentoo packages HEAD just fine.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
123456 ... 8