On Monday, June 6, 2016 23:15:00 -0700, Herbert Valerio Riedel wrote:
Unfortunately, GHC's `base` package has a *huge* API surface. So with> each GHC release we're usually forced to perform a major version bump to satisfy the PVP, even if just a tiny part only very few packages use of `base`'s API became backward in-compatible. This may be addressed by reducing the API surface of `base` by moving infrequently used GHC-internal-ish parts of the API out of base.
1. I hope the compartmenting of `base` will be done soon. The PVP's purpose is subverted by the frequent churning of `base` versions. 2. On /r/haskell I suggested that a package's dependencies be treated as metadata that can be maintained independently of the package itself. For example, if `foo-x.y.z.w` works with dependency `bar-a.b.c.d`, this would be included in `foo`'s .cabal file (the current practice). However, if a new version of `bar` is later found to be compatible, this fact would be stored in the external metadata (without having to update `foo-x.y.z.w`'s .cabal file), and cabal would look at this external metadata when calculating acceptable versions of `bar`. This would avoid *unnecessary* domino updates to packages in cases when their dependencies are updated in a compatible fashion. 3. In general, the granularity of package versions tracked by the PVP should be reconsidered. Ideally, each externally visible function should be tracked separately, which would allow using upward compatible versions of packages in many more cases than the PVP allows at present. Whether this finer granularity would be worth the added complexity should be given a fair trial. This tracking could be partially automated with a tool to compare the current package version with its update to identify formal changes. Semantic changes would still have to be noted manually. Howard