Ian Lynagh | 19 Mar 23:35 2013

Release plans


Hi all,

Thank you to everyone who gave us feedback on when we should release
7.8.1, and on future release plans in general. We've looked at all the
responses, and we think that the best plan is to continue to make major
releases annually, with minor "patch-level" releases between them.

Additionally, we may recommend particular snapshots, and provide binary
builds for all tier-1 platforms, for people who wish to test new
features etc in HEAD.

There is more detail on how all this will work here:
    http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases

We will therefore aim for a 7.8.1 release in October. We do not
currently expect to make a 7.6.3 release, although that may
change if serious bugs in 7.6.2 are discovered.

Would a 7.7.x recommended snapshot be useful to you? Tell us if you
want one. Compared to 7.6 it would contain:
  * polykinded Typeable library
  * 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
(Continue reading)

Jan Stolarek | 20 Mar 08:41 2013
Picon

Re: Release plans

Hi Ian,

I think it would make sense to post this on haskell-cafe. I think we can expect larger response 
from there than from glasgow-haskell-users.

Janek

Dnia wtorek, 19 marca 2013, Ian Lynagh napisaƂ:
> Hi all,
>
> Thank you to everyone who gave us feedback on when we should release
> 7.8.1, and on future release plans in general. We've looked at all the
> responses, and we think that the best plan is to continue to make major
> releases annually, with minor "patch-level" releases between them.
>
> Additionally, we may recommend particular snapshots, and provide binary
> builds for all tier-1 platforms, for people who wish to test new
> features etc in HEAD.
>
> There is more detail on how all this will work here:
>     http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases
>
>
>
> We will therefore aim for a 7.8.1 release in October. We do not
> currently expect to make a 7.6.3 release, although that may
> change if serious bugs in 7.6.2 are discovered.
>
>
> Would a 7.7.x recommended snapshot be useful to you? Tell us if you
(Continue reading)

John Wiegley | 20 Mar 11:58 2013

Re: Release plans

>>>>> Ian Lynagh <ian <at> well-typed.com> writes:

> Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
> one.

I think that could very useful, sort of like what the Linux kernel did before
they stopped.

I'm never sure if building from HEAD will produce a compiler I should use for
getting real work done, but I wouldn't have the same reservations concerning a
7.7.x "interim developer release".

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Carter Schonwald | 20 Mar 18:23 2013
Picon

Re: Release plans

A 7.7 snapshot would be useful for me in a number of ways: 

a) I often spend some time prior to recent GHC releases trying to build all the various major packages, and often send in patches to  maintainers during that window (or at least the start of patches). Having a fixed snapshot release that maintainers can use to validate any such future proofing patches would be tremendously helpful

b) Theres a bunch of engineering i'm currently up where I want to use some of the features very soon, and making it easier for other people to use the open source subsets of that engineering sooner rather than later would be valuable!

c) lowering the barrier to folks using and stress testing these features may catch problems sooner. 

note: i'm ok with compiling ghc from source, but many people who might be happy to test those new features might find that a bit daunting the first time.

cheers
-Carter


On Wed, Mar 20, 2013 at 6:58 AM, John Wiegley <johnw <at> fpcomplete.com> wrote:
>>>>> Ian Lynagh <ian <at> well-typed.com> writes:

> Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
> one.

I think that could very useful, sort of like what the Linux kernel did before
they stopped.

I'm never sure if building from HEAD will produce a compiler I should use for
getting real work done, but I wouldn't have the same reservations concerning a
7.7.x "interim developer release".

--
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Iavor Diatchki | 20 Mar 20:55 2013
Picon

Re: Release plans

Hello,

I think that there are a lot of useful features that are in HEAD that would be useful to a wider audience than GHC devs, so a release before October would certainly be useful.  I don't think it is that important if it is called 7.7.1 or 7.8.1 but I think that it needs to be a fixed version, in the sense that all code (including GHC libraries) is tagged in the repos and, possibly, we make an entry for it in the track system, so that people can record bugs against it.

Given that GHC is very actively developed, it might make sense to have one of these "snapshot" releases every 3 or so months, as "technology preview", and without any promises about stability or compatibility (in particular, they should not be considered for inclusion in the HP or standard Linux distributions).   This would give us a fairly low over-head middle ground between the volatility of nightly builds, and the long time between official releases.

-Iavor



On Wed, Mar 20, 2013 at 10:23 AM, Carter Schonwald <carter.schonwald <at> gmail.com> wrote:
A 7.7 snapshot would be useful for me in a number of ways: 

a) I often spend some time prior to recent GHC releases trying to build all the various major packages, and often send in patches to  maintainers during that window (or at least the start of patches). Having a fixed snapshot release that maintainers can use to validate any such future proofing patches would be tremendously helpful

b) Theres a bunch of engineering i'm currently up where I want to use some of the features very soon, and making it easier for other people to use the open source subsets of that engineering sooner rather than later would be valuable!

c) lowering the barrier to folks using and stress testing these features may catch problems sooner. 

note: i'm ok with compiling ghc from source, but many people who might be happy to test those new features might find that a bit daunting the first time.

cheers
-Carter


On Wed, Mar 20, 2013 at 6:58 AM, John Wiegley <johnw <at> fpcomplete.com> wrote:
>>>>> Ian Lynagh <ian <at> well-typed.com> writes:

> Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
> one.

I think that could very useful, sort of like what the Linux kernel did before
they stopped.

I'm never sure if building from HEAD will produce a compiler I should use for
getting real work done, but I wouldn't have the same reservations concerning a
7.7.x "interim developer release".

--
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian Lynagh | 21 Mar 01:08 2013

Re: Release plans


We've had long discussions about snapshot releases, and the tricky part
is that while we would like people to be able to try out new GHC
features, we don't want to add to the burden of library maintainers by
requiring them to update their libraries to work with a new GHC release
more than once a year.

The impression that I have from the responses so far is that most people
who would like a snapshot release want to use it as their regular
compiler, which will probably mean they want to use other libraries with
it, which in turn will probably mean changes to libraries are needed
(even if only bumping version bounds). It's therefore likely to mean
more work for library maintainers (even if it's only checking and
applying patches, it's still work).

On Wed, Mar 20, 2013 at 01:23:04PM -0400, Carter Schonwald wrote:
> 
> a) I often spend some time prior to recent GHC releases trying to build all
> the various major packages, and often send in patches to  maintainers
> during that window (or at least the start of patches). Having a fixed
> snapshot release that maintainers can use to validate any such future
> proofing patches would be tremendously helpful

Thank you for doing this, but doing it for snapshot releases too would
probably double the work most maintainers need to do.

But perhaps we should announce a "library API freeze" some time before
the first RC on a stable branch. That way people can safely update their
dependencies at that point, and by the time the RC is out people testing
the RC will be able to test more without running into problems
installing libraries.

Thanks
Ian
John Lato | 21 Mar 03:21 2013
Picon

Re: Release plans

On Thu, Mar 21, 2013 at 8:08 AM, Ian Lynagh <ian <at> well-typed.com> wrote:

We've had long discussions about snapshot releases, and the tricky part
is that while we would like people to be able to try out new GHC
features, we don't want to add to the burden of library maintainers by
requiring them to update their libraries to work with a new GHC release
more than once a year.

But perhaps we should announce a "library API freeze" some time before
the first RC on a stable branch. That way people can safely update their
dependencies at that point, and by the time the RC is out people testing
the RC will be able to test more without running into problems
installing libraries.

What would be ideal would be if this "library API freeze" coincided with the snapshot (odd-numbered) release.  Then library maintainers would only have to update once, and hopefully many of them would have their updates available before ghc's stable release.

John L.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian Lynagh | 21 Mar 13:16 2013

Re: Release plans

On Thu, Mar 21, 2013 at 10:21:25AM +0800, John Lato wrote:
> 
> What would be ideal would be if this "library API freeze" coincided with
> the snapshot (odd-numbered) release.

I was only thinking of about a 2 week period, and only on the stable
branch. Freezing the library APIs in HEAD after a snapshot release would
mean it wouldn't be possible to do anything that required a library API
change for 6+ months, which I don't think would be the best solution.

Thanks
Ian
Nicolas Trangez | 21 Mar 13:26 2013

Re: Release plans

On Thu, 2013-03-21 at 12:16 +0000, Ian Lynagh wrote:
> On Thu, Mar 21, 2013 at 10:21:25AM +0800, John Lato wrote:
> > 
> > What would be ideal would be if this "library API freeze" coincided with
> > the snapshot (odd-numbered) release.
> 
> I was only thinking of about a 2 week period, and only on the stable
> branch. Freezing the library APIs in HEAD after a snapshot release would
> mean it wouldn't be possible to do anything that required a library API
> change for 6+ months, which I don't think would be the best solution.\

6+ months might indeed be long, but I think it would be useful to have
an "core library API freeze" some time before a new GHC release, in
order to allow (non-core) library maintainers to update their code to
work with the libs shipped with the then-upcoming GHC release, in order
to reduce the waiting period before users can actually use the new GHC
release (due to libs not compiling) becomes shorter.

Nicolas
Conrad Parker | 21 Mar 02:57 2013

Re: Release plans

On 20 March 2013 18:58, John Wiegley <johnw <at> fpcomplete.com> wrote:
>>>>>> Ian Lynagh <ian <at> well-typed.com> writes:
>
>> Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
>> one.
>
> I think that could very useful, sort of like what the Linux kernel did before
> they stopped.
>
> I'm never sure if building from HEAD will produce a compiler I should use for
> getting real work done, but I wouldn't have the same reservations concerning a
> 7.7.x "interim developer release".

likewise.

I'd be happy with just a git tag and an email to this list every month
or two indicating that there's a probably-ok version that could do
with some testing. This could happen whenever a feature lands and the
dust has settled a bit.

Conrad.
Carter Schonwald | 21 Mar 07:50 2013
Picon

Re: Release plans

likewise! just having that precise tagged info for how to pick a stable code state for ghc + associated libraries even if it wasn't a full "dev preview" release would make me a lot less conservative about using HEAD ghc more often / even as my default


On Wed, Mar 20, 2013 at 9:57 PM, Conrad Parker <conrad <at> metadecks.org> wrote:
On 20 March 2013 18:58, John Wiegley <johnw <at> fpcomplete.com> wrote:
>>>>>> Ian Lynagh <ian <at> well-typed.com> writes:
>
>> Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
>> one.
>
> I think that could very useful, sort of like what the Linux kernel did before
> they stopped.
>
> I'm never sure if building from HEAD will produce a compiler I should use for
> getting real work done, but I wouldn't have the same reservations concerning a
> 7.7.x "interim developer release".

likewise.

I'd be happy with just a git tag and an email to this list every month
or two indicating that there's a probably-ok version that could do
with some testing. This could happen whenever a feature lands and the
dust has settled a bit.

Conrad.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow | 19 Jul 15:41 2004
Picon

RE: Release plans

On 19 July 2004 14:20, Shae Matijs Erisson wrote:

>>   - generalised algebraic data types (currently in development, might
>>     not make it into the release).
> 
> What does this mean exactly?

http://research.microsoft.com/Users/simonpj/papers/gadt/index.htm

> Ian Lynagh has built ghc-cvs debs, is anything in particular ghc-cvs
> users should try to test?

The new backend stuff isn't on the mainline yet, it's on the
backend-hacking-branch (and there's a *lot* of uncommitted stuff in my
local tree).  Large changes are coming on the HEAD before the release,
so hold on tight.

Cheers,
	Simon
Simon Marlow | 20 Jul 10:29 2004
Picon

RE: Release plans

On 20 July 2004 01:43, Bernie Pope wrote:

> Since you are working on the backend is there any chance that GHC
> could support symbol names in the heap?
> 
> I tried to add this previously and failed miserably.
> 
> I would be happy with a flag, such as '-debug-symbols' or somesuch,
> that keeps source symbol names, at least for data constructors, and
> possibly functions.
> 
> This would be a BIG win for buddha and possibly other debugging tools.
> 
> Currently I have to turn on -prof which is a bad hack.

This is a good suggestion, but it's unlikely that we'll have time to add
it before the release.  I'd like to see us support more debugging
information, preferably in a way that can be stripped from a binary.

I'm not sure that we want to have yet another "way" to build libraries.
Debugging is something that should be easy, otherwise the effort is too
much and we resort to using Debug.trace (I'm guilty of this - I confess
to never having tried any of the available debuggers simply because
they're not immediate enough).

> Will there be any big changes to the heap representation of objects
> with the new backend?

No change at all.

Cheers,
	Simon
Bernie Pope | 20 Jul 11:29 2004
Picon
Picon

Re: Release plans

On Tue, Jul 20, 2004 at 09:29:38AM +0100, Simon Marlow wrote:
> On 20 July 2004 01:43, Bernie Pope wrote:
> 
> > Since you are working on the backend is there any chance that GHC
> > could support symbol names in the heap?
> > 
> > I tried to add this previously and failed miserably.
> > 
> > I would be happy with a flag, such as '-debug-symbols' or somesuch,
> > that keeps source symbol names, at least for data constructors, and
> > possibly functions.
> > 
> > This would be a BIG win for buddha and possibly other debugging tools.
> > 
> > Currently I have to turn on -prof which is a bad hack.
> 
> This is a good suggestion, but it's unlikely that we'll have time to add
> it before the release.  I'd like to see us support more debugging
> information, preferably in a way that can be stripped from a binary.

Good point.

> I'm not sure that we want to have yet another "way" to build libraries.

I'm with you on that one. 

> Debugging is something that should be easy, otherwise the effort is too
> much and we resort to using Debug.trace (I'm guilty of this - I confess
> to never having tried any of the available debuggers simply because
> they're not immediate enough).

True. 

In the back of my mind I had the notion that C-- would provide some
infrastructure for symbol tables and whatnot.  

Anyway I can see that this is not the kind of thing to jump into too hastily. 

Cheers,
Bernie.
Alastair Reid | 20 Jul 14:00 2004
Picon

Re: Release plans

> I'd like to see us support more debugging
> information, preferably in a way that can be stripped from a binary.

The easy way would be as .stabs entries since that's what gdb uses.

However, stabs entries themselves are absolutely horrible (the design 
obviously started simple and acquired a bunch of ad hoc hacks along the way).

But if you're willing to encode everything as strings, you could spit out a 
bunch of what look like filename directives but put general data in the 
strings instead of filenames.

(Or read up on stabs directives carefully and try to force-fit Haskell into a 
design made for C, C++, etc.)

--
Alastair

Gmane