[Haskell-cafe] ANN: HDBC v2.0 now available

[Yitzchak Gale]

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