Dependencies/backwards compatibility in Hackage

[Sven Moritz Hallberg]

Hi everyone,

While trying out cabal-install today, I stumbled across the following:
I wanted to install XmlRpc which depends on HaXml and works with
HaXml-1.13.2. However, HaXml-1.17 which has also been uploaded to
hackageDB changed an exposed module's name and XmlRpc doesn't work with
it anymore.

I'm wondering how to avoid such situations. I appears to me that
expecting the maintainer of every package depending on HaXml to update
their dependencies "after the fact" doesn't make sense because it leaves
an arbitrarily long window where the package won't build straight out
of hackageDB.

Wouldn't it be sensible for the author of HaXml to specify in the .cabal
file for version 1.17 whether it is backwards-compatible or not?
I'd imagine a field like "compatible:" or something to name any older
versions that this version is backwards-compatible to, e.g.

    name: base
    version: 2.0
    compatible: 1.0
    ...

The field would default to "not backwards-compatible to anything" so it
would fail safe in the case where it's not given.

There would still be the possibility of the maintainer erroneously
stating compatibility where there is none. For example, she could set
the field at some point and forget to update it. There might be a
clever way to avoid this pitfall, though.

What's the general opinion, should something like the above be added?
(I'd be willing to volunteer for the code work.)

On a side note, it probably wouldn't be too hard with existing tools to
build a "gatekeeper" program to detect obvious kinds of flux in the API
when uploading a new package to hackageDB: Check that all old modules
are there, export all old functions, and maybe whether all the old
functions still have the same type signatures (otherwise warn and ask
for confirmation...), etc.


Regards,
Sven Moritz