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.tib...@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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
