Avoiding bumping the major version of base in every release

[Johan Tibell]

Hi!

Bumping the major version number of base creates a bunch of work for
package maintainers. Some times this work is justified, when there were
actual non-backwards compatible API changes and maintainers need to fix
their code. Often the work is busy work, as there were no real breakages
and maintainers need to update their version bounds and make a new release.

When bumps to the major version leads to busy work, maintainers often
express a desire to get rid of version bounds altogether. While that might
be a natural reaction, I don't think that's actually a good idea and it
will lead to more breakages in the end*.

All this is to say, we should try to avoid major version bumps to base.
Here's my suggestion

*Short term*

   - Make sure we only bump the major version number when we actually make
   a breaking change. We don't need to bump base because the major GHC version
   number changed.
   - Try harder to not make breaking changes. Breaking changes has a very
   high cost to users and are seldom worth it to them. For example, avoid
   renaming functions just because the new name feels cleaner. Just add a new
   function and have the old function call the new function. All successful
   languages do this.

*Medium term*

   - Break up base a bit. There are several other good reasons to do this,
   but having a monolithic base means that breaking changes to the most
   obscure modules cause a major version bump for the package as a whole.

* But in the case of missing upper bounds, the breakages and extra work
falls on the users of libraries, not on their maintainers. That's really
bad as the users are not really in a position to deal with the breakages.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140409/751635fd/attachment.html>