Another API stability plea

[John Goerzen]

Hi folks,

Recently, I received this bug report against testpack:

http://github.com/jgoerzen/testpack/issues#issue/1

The program worked fine with QuickCheck 2.1.0.2 but failed to compile 
against 2.1.0.3, producing the error message listed.

The fix is at 
http://github.com/jgoerzen/testpack/commit/7a8e30d419a52c96e212c6df48799c73ec841edb 
if you're curious.

I'm writing because there was an API change in a point release.  This is 
violating our convention and the Platform policy.  As a practical 
matter, it makes life more difficult for me because:

  * If I were to add an upper bound to a dependency in .cabal, with the 
intent to prevent compilation errors due to API changes, this would 
break that.

  * I can't use CPP macros to support both the old and new versions 
because Cabal assumes that in a package named a.b.c.d, the .d component 
isn't relevant to API changes (since that's the policy and convention).

  * I get bug reports from users that can't install my software at an 
unexpected time.

So, please take this as a polite request and reminder to make a more 
significant version change in your .cabal when you change the API.

Here is a link to the versioning policy:

http://www.haskell.org/haskellwiki/Package_versioning_policy

A.B.C should uniquely identify an API.

Also I would like to remind everyone that adding or removing instances 
is an API change and can break code, as with the added instances in time 
a little while back.

I generally try to support as wide a range of library versions as 
possible with my code, so that it can be readily installed on machines 
ranging from Debian stable to bleeding-edge Hackage libraries.  Having 
API changes untestable with CPP breaks that.

Thanks for your time.  I'll exit the "get off my lawn" mode now ;-)

-- John