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