Another API stability plea

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