GHC 7.8 release?

Austin Seipp mad.one at gmail.com
Thu Feb 7 20:46:59 CET 2013


This is a slight tangent but, I am always somewhat confused about the
release schedule. When reading this, the basic decision seems to come
down to when do we cut a release, taking into account factors like
reliability/bugs/support/community/other stuff like that.

So, IMO, perhaps one thing that's needed is a more formalized release
schedule, with something like a merge window for 'big changes'? For
example, many projects like LLVM and GCC have fairly fixed release
windows, with an accompanying merge window several months before an
official release. (The Linux kernel does this too, but they have a
much shorter cycle.) If a large feature misses the merge window, it
must go into the next release.

Personally, I am not too worried about necessarily getting every new
feature into a release, even if they're awesome (and they all are!)
And while giving HP users the latest and greatest is great, they want
stability more than anything, in my opinion. So I think they're fine
with that too. What I am worried about is there being a good length of
time where the features integrated have time to bake and see some
polish, without a lot of interference.

There are a lot of issues with this including how to deal with work
that goes on in the mean time, etc. GHC also has far less manpower and
a much different ratio of developer influence and 'spread' than any of
the above projects. And we have to define what qualifies as 'big
change.' But if the issue seems to be one of time, synchronization,
and quality, perhaps we should think about whether or not a change
like a more formalized schedule could help.

I think making releases so people can find bugs is important. But that
will always happen anyway, so I'd rather be a little cautious and wait
this one out, than try to cram it. The new vectoriser only came in
within the past ~48 hours, and SIMD was just pushed in the past week
(and DPH will need SIMD support merged, too!) I think Feburary or even
March is way, way too early for a solid release, and it's certainly
too late for the HP anyway. I see little pain in postponement,
personally.

On Thu, Feb 7, 2013 at 2:25 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Dear GHC users,
>
>
>
> Carter: Will this RTS update make it into ghc 7.8 update thats coming up in
> the next monthish?
>
> Andreas: We are almost there - we are now trying to sort out a problem on
> mac os x. It would be helpful to know if there is a cutoff date for getting
> things into 7.8.
>
>
>
> Simon, Ian, and I have just been discussing 7.8, and would be interested in
> what you guys think.
>
>
> At ICFP we speculated that we’d make a release of GHC soon after Christmas
> to embody tons of stuff that has been included since 7.6, specifically:
>
> ·         major improvements in DPH (vectorisation avoidance, new
> vectoriser)
>
> ·         type holes
>
> ·         rebindable list syntax
>
> ·         major changes to the type inference engine
>
> ·         type level natural numbers
>
> ·         overlapping type families
>
> ·         the new code generator
>
> ·         support for vector (SSE/AVX) instructions
>
>
>
> Whenever it comes it would definitely be great to include Andreas & friends’
> work:
>
> ·         Scheduler changes to the RTS to improve latency
>
>
>
> The original major reason for proposing a post-Xmas release was to get DPH
> in a working state out into the wild.  However, making a proper release
> imposes costs on everyone else.  Library authors have to scurry around to
> make their libraries work, etc.   Some of the new stuff hasn’t been in HEAD
> for that long, and hence has not been very thoroughly tested.   (But of
> course making a release unleashes a huge wave of testing that doesn’t happen
> otherwise.)
>
>
>
> So another alternative is to leave it all as HEAD, and wait another few
> months before making a release.  You can still use all the new stuff by
> compiling HEAD, or grabbing a snapshot distribution.  And it makes it hard
> for the Haskell platform if GHC moves too fast. Many people are still on
> 7.4.
>
>
>
> There seem to be pros and cons each way.  I don’t have a strong opinion.  If
> you have a view, let us know.
>
>
>
> Simon
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,
Austin



More information about the ghc-devs mailing list