Proposal: Remove Control.Concurrent{QSem, QSemN, , SampleVar, mergeIO, nmergeIO} from base

[Ganesh Sittampalam]

On 07/06/2012 18:21, Bryan O'Sullivan wrote:
> On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk <v.dijk.bas at gmail.com
> <mailto:v.dijk.bas at gmail.com>> wrote:
> 
>     On 7 June 2012 14:46, Ian Lynagh <igloo at earth.li
>     <mailto:igloo at earth.li>> wrote:
>     > I propose that we remove ... from base.
> 
>     Shouldn't they first get through a deprecation cycle?
> 
> 
> I don't see any value to that; it just adds a year of latency.
> 
> We have plenty of evidence that "this will break in the next release"
> warnings are ignored until after that next release, when people who
> update are finally forced to confront stuff being broken.

Deprecation for a release provides a window for people who are
conscientious but would rather have a window in which to deal with this
kind of issue rather than be pressured to fix it immediately so that
their code works with the latest and greatest GHC. This is a particular
issue if you maintain a low-level library.

As a more general point, a principle of breaking things immediately also
makes it very hard for people who want to support multiple versions of
GHC or the platform. Even one release worth of deprecation is quite
difficult if the replacement is introduced in version x and the obsolete
version removed completely in version x+1, since there is nothing that
will work in x-1, x and x+1. If you want your software to build in
Debian sta[b]le as well as the bleeding edge, supporting three versions
is often necessary.

In this case the replacement is an external library so can in theory be
adopted immediately, but a maintainer would need to be following this
list to know about the need to do so.

So +1 for a cycle of deprecation, -1 for immediate removal.

Ganesh