checking upper bounds on base

[Ian Lynagh]

On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
> 
> You mentioned in the ticket that we need to have base strictly following
> the PVP. That's true of course. I'm assured by the GHC hackers that
> they're committed to the PVP. The reason for bumping 4.0 -> 4.1 is being
> looked at but their first guess is that it was the change in GHC's
> finaliser semantics (which did indeed break a couple programs).

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.*.

We could also be stricter about API changes in the bootlibs, but that
limits our ability to fix bugs.



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.

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?

We certainly haven't been trying to obey the PvP in the GHC package, as
most of the compiler's code is exposed, so it becomes hard to fix bugs
in the compiler. But should the libraries that GHC ships with within a
stable branch all have the same major version number?


Thanks
Ian