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