I really really think this is the wrong way to go. Occasional destruction is desperately needed for progress, else things will invariably stagnate.
I disagree. Having everything fail (we measured it as ~90% of hackage) when people upgraded to ghc-6.10 would have been a disaster. Do you recall the screaming, wailing and gnashing of teeth after the release of ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers) got a lot of flak for not making the upgrade process easier and needlessly breaking everyone's perfectly good packages.
90%? That sounds like an awful lot for the relatively minor changes with base-4. I guess a number of packages will use exceptions, and others with use Data and Typeable, but 90%? I don't doubt you when you say that you measured it though, just marvelling. If 90% of hackage would truly break, then I agree that we might need more caution than my radical approach. But I'm not fully convinced there either. After all, unlike with the ghc-6.8 release, all that's needed for a package to work again is to upload a new .cabal that makes the dependency on base-3 explicit, if an author really doesn't want to update the codebase. And even for those packages where library authors don't do that simple step, all that's needed of the user of the library is to specify the base-3 constraint when running cabal-install. My main complaint is really that there is currently no incentive whatsoever for library authors to migrate. If we make base-4 the default, it will require just a little bit of work to make packages that depend on base-3 work anyway, as seen above. It's not so much work that it should incur any screaming, wailing and teeth gnashing. But it should be just enough work to encourage action in one way or another, either truly migrating the code or just making the dependency explicit as I noted above. I think it would be hard to find a more accurate, and non-intrusive, incentive. :-) I definitely agree with your suggestion to make hackage require an upper bound on base. But that's to make us future proof, it won't solve the issue here and now. Cheers, /Niklas