checking upper bounds on base

[Ross Paterson]

On Tue, Jun 02, 2009 at 01:27:48PM +0100, Ian Lynagh wrote:
> The reason base's version was bumped from 4.0 to 4.1 is that there were
> some changes that required it, according to the PvP, e.g.
>     GHC.Conc.signalHandlerLock
> was removed.
> 
> I don't know if there were any such changes in non-GHC.* modules, as I
> stopped looking when I found the first change.
> 
> For the future, one option would be to exclude GHC.* from the PvP
> requirements, although then you have problems with any package which
> uses GHC.*.

It used to be the policy that there were usually no API changes in the
stable branch, which in PVP terms would mean that only the 4th component
of library package version numbers would be incremented.  However it
seems that the base split has made that much more difficult to maintain,
at least for base.  Worse, it seems there are about a hundred packages
on hackage importing GHC.* modules other than the advertised GHC.Exts,
so excluding them seems impossible.  So perhaps the version number policy
for base is now a refinement of the PVP:

- increment 1st digit on a new major release of GHC
- increment 2nd digit after an unavoidable API change in a stable branch
- increment 3rd digit after an unavoidable API addition in a stable branch
- increment 4th digit for bugfix-only changes in a stable branch

Please confirm.

Other core packages released with GHC shouldn't have this problem, and
should be able to stick to bugfixes only in stable branches, and don't
need to be automatically incremented.  (Still the extensible-exceptions
and unix packages bumped minor version numbers in the 6.10 series.)

> Incidentally, randomly increasing library version numbers doesn't
> actually break the PvP, although doing it is bad as it makes more work
> for users of the package.

It collides with the push to specify upper bounds on dependencies.
There's a need to minimize increments to version numbers, because
spontaneous increments unnecessarily break such packages.

> The only sense in which this actually broke the PvP is that base's major
> version was increased, but base is "part of" GHC, and GHC's major
> version number wasn't increased. Which raises the question, is GHC's
> version number intended to follow the PvP?

I wouldn't expect GHC (or the ghc library package) to follow the PVP.