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