checking upper bounds on base
Hi Ross, I'd like to get Hackage using the new check for base being bounded above. I think it'll make a big difference when it comes to future ghc/base upgrades. The last one was papered over by cabal-install defaulting to base 3 when the package author did not specify otherwise. That will not work forever. 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). For the practical issues: I'll can send announcement to the haskell (+cafe) mailing list explaining what people have to do and the rationale. There have been a number of changes in the Cabal lib recently, it may be that you prefer to just pull the checking patch for the hackage-scripts rebuild, rather than everything. OTOH, I don't expect any problems from pulling everything as the changes have been mostly in the build system side of things. What do you think? Is this a sane plan? Duncan
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
I'd like to get Hackage using the new check for base being bounded above. I think it'll make a big difference when it comes to future ghc/base upgrades. The last one was papered over by cabal-install defaulting to base 3 when the package author did not specify otherwise. That will not work forever. [...] For the practical issues:
I'll can send announcement to the haskell (+cafe) mailing list explaining what people have to do and the rationale.
It's ready to go. Would you like to send your announcement first?
On Tue, 2009-06-02 at 11:35 +0100, Ross Paterson wrote:
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
I'd like to get Hackage using the new check for base being bounded above. I think it'll make a big difference when it comes to future ghc/base upgrades. The last one was papered over by cabal-install defaulting to base 3 when the package author did not specify otherwise. That will not work forever. [...] For the practical issues:
I'll can send announcement to the haskell (+cafe) mailing list explaining what people have to do and the rationale.
It's ready to go.
Thanks Ross!
Would you like to send your announcement first?
Sent. I also realised if we're encouraging people to use: build-depends: base >= 3 && < 5 then cabal should be picking base 4 in this case. That was ticket http://hackage.haskell.org/trac/hackage/ticket/485 which I've just now implemented, but it need testing, back-porting and releasing as cabal-install-0.6.4. Duncan
On Wed, 2009-06-03 at 11:45 +0100, Ross Paterson wrote:
On Wed, Jun 03, 2009 at 11:36:56AM +0100, Duncan Coutts wrote:
On Tue, 2009-06-02 at 11:35 +0100, Ross Paterson wrote:
Would you like to send your announcement first?
Sent.
OK, I've updated the scripts.
Yay. Works for me. Thanks very much. I really need to make cabal upload [--check] report the errors properly now. Currently only emits them at -v3 :-) Duncan
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
On Tue, Jun 2, 2009 at 2:27 PM, 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.*.
I don't think so as low level libraries like network must use GHC modules for functions like threadWaitRead. If network's dependencies don't follow PVP so can't network itself, etc. Cheers, Johan
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.
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
On Tue, Jun 02, 2009 at 09:19:44PM +0100, Ross Paterson wrote:
On Tue, Jun 02, 2009 at 08:53:19PM +0100, Ian Lynagh wrote:
I don't think the base split made much difference.
It forced the exposure of a lot more GHC.* modules, I think.
In 6.6.1, before any splitting, there were no hidden modules; all the GHC.* modules were exposed (in libraries/base/package.conf.in; base.cabal wasn't used by GHC's build system then, and we didn't have the conditional syntax to only list those modules when building for GHC).
But I think my question is answered: just use base < 5 or base == 4.*
I didn't mean to answer the Big Question. I don't have strong feelings about it. I'd be happy with that answer, though. My main worry with it would be that people would do likewise for other packages. Thanks Ian
participants (4)
-
Duncan Coutts -
Ian Lynagh -
Johan Tibell -
Ross Paterson