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