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-4.7.0.0 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 well justified.
- 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.