Avoiding bumping the major version of base in every release
Herbert Valerio Riedel
hvriedel at gmail.com
Wed Apr 9 12:17:52 UTC 2014
On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote:
> 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.
Fwiw, I did go over the changes in base-220.127.116.11 when I compiled the
changelog to check whether the major bump was justified; but since a
couple of deprecated functions where removed, several new typeclass
instances were added (however, this isn't a justification anymore), the
rather disruptive Typeable change occured, as well as the PrimBool
changes (which may leak into the API exposed by base) I believed it was
> - 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.
Aren't we already following this practice in base?
> *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.
More information about the ghc-devs