Avoiding bumping the major version of base in every release

[Johan Tibell]

I just noticed that 7.8.1 bumps the major version of base, but I can't see
any breaking changes in the release notes:
http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/release-7-8-1.html


On Wed, Apr 9, 2014 at 12:00 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> 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/c3062cd0/attachment.html>