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

On 07/06/2012 18:21, Bryan O'Sullivan wrote:

On Thu, Jun 7, 2012 at 10:02 AM, Bas van Dijk mailto:v.dijk.bas@gmail.com> wrote:

On 7 June 2012 14:46, Ian Lynagh mailto:igloo@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