checking upper bounds on base

[Ian Lynagh]

On Tue, Jun 02, 2009 at 08:03:55PM +0100, Ross Paterson wrote:
> 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,

Well, it was more like
    "We will usually not merge patches which cause API changes"

I don't have numbers, but I expect most releases had a couple of API
changes that were considered small enough and important enough to be let
in.

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

I don't think the base split made much difference. I don't think much
more internal stuff is exposed because of it, and packages like unix and
network were already separate.

In fact, if anything it should help, as there is a greater chance that a
necessary API change is in a separate package that relatively few other
packages depend on.

> Worse, it seems there are about a hundred packages
> on hackage importing GHC.* modules other than the advertised GHC.Exts,

It would be good to find out why they need to, or to fix them if they
don't.

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

You mean, "base follows the PvP, but we recommend you use a <x dep
rather than <x.y, and we'll try to avoid breaking your package"?

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

For example, unix gained an export of
    System.Posix.Process.Internals.decipherWaitStatus
and extensible-exceptions gained
    Control.Exception.Extensible.throwTo

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

Agreed.

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

Then shouldn't it be fine for GHC 6.10.1 to come with base 4.0, and
6.10.3 to come with base 4.1?

Of course, it'll create a lot of work if lots of packages have
    base < 4.1
deps, and because base is so wide, the vast majority of the time the API
change won't affect the dependees.

Maybe the answer is just to be even more conservative about API-altering
changes for the bootlibs in a GHC stable branch.


Thanks
Ian