On Sun, 2009-02-01 at 17:22 +0100, Niklas Broberg wrote:
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.
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015654.h... Most non-trivial packages either use exceptions or depend on a package that uses exceptions (or syb). The 90% is from memory however. I can't find our exact measurements. I think we may have given up trying to measure precisely after it became obvious that nothing was working.
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.
I think in the end we managed to get it down to around 5% breakage which I felt was a pretty good result.
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,
For the most part that was all that was required for 6.8 too, to add dependencies on the new packages split out of base. People still complained. A lot. :-)
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.
But people do not know that. It has to work by default (even if it warns).
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 think the right place to put incentives is in checks in new uploads to hackage. Making existing packages break should be avoided when possible, even when the changes the developer needs to make are trivial. Many many end users have no idea how to make these trivial changes and it is not our intention to punish them. From the perspective of an end user just trying to install something it either works or it doesn't. When a large proportion stop working is when the teeth gnashing starts. Also remember that many packages do not have very active maintainers.
I definitely agree with your suggestion to make hackage require an upper bound on base. But that's to make us future proof,
True.
it won't solve the issue here and now.
What do you think about the suggestions in my other reply? I hope that is a reasonable suggestion to encourage a transition to base 4 without punishing end users. Duncan