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@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 wrote:

...

...

...

...

...

> Ian Lynagh 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

On Thu, Mar 21, 2013 at 8:08 AM, Ian Lynagh 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.

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

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

On 20 March 2013 18:58, John Wiegley wrote:

...

...

...

...

...

> Ian Lynagh 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users