Duncan Coutts wrote:
So in the next cabal-install release (which should be pretty soon now) configure will do the same thing and pick base 3 unless you specify build-depends base >= 4.
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... would have been a disaster... during the lifespan of base 4 we need to encourage new releases to start working with it... Doing that with warnings hints etc is the way to go.
No, that's not good enough either. Existing packages will just stay with old versions to avoid the work, and new packages will then also use old versions for maximum compatibility. The incentive is not strong enough. Those warnings and hints must have teeth. Comparing with what has happened in other languages, which have stagnated or not stagnated at various rates, it is clear that what we need is a well-defined deprecation process. The warnings should say something like: you had better upgrade this, otherwise it will stop working in the next version. Both maintainers and users should be aware of this threat. That way, code that is maintained will not stop working. There will be plenty of time to make the change. Code that is used but not maintained will generate a hue and cry among the users that will hopefully motivate someone to do something about it. Code that is not maintained and little used will eventually be destroyed, but that code is probably bitrotting in any case. The deprecation process can be as slow and fine-grained as we like. But there must be a well-defined point in the future when old unmaintained code will be allowed to stop working.
Destruction is not such a friendly approach. We do not need to make the users suffer
When done carefully, gradually, and with plenty of warning (at least one full version cycle), destruction is indeed friendly and helpful. It allows users to understand precisely what versions should be used, and when, in old, current, and future projects, while permitting Haskell to march steadily onward. -Yitz