Release plans

[Ian Lynagh]

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