Björn Bringert
But then what is your answer to the problem of things breaking in the time between the release of HaXml 1.17 and making a new release of haxr?
-Sven
I don't really have one, expect fast development :-).
Okay, but that's unreliable. The way I see it, the upshot of it would be that cabal-install would only actually work half the time. No fun!
One possibility would be to have a convention about version number changes when libraries make backwards-incompatible API changes. E.g. HaXml should change major version whenever a change would break something that depends on it. Then all libraries which depend on HaXml could specify:
Build-depends: HaXml >= 1.13 && < 2
or something like that. The only problem would be that it would be overly restrictive if a HaXml 2.0 comes out that the current version of the depending library actually works with.
What's wrong with the solution I proposed, i.e. to add an explicit field to the package description which states whether we broke compatibility or not? It's effectively the same as a version numbering convention without having to tell everyone how to assign their numbers. Don't get me wrong, I'd be all for a consistent numbering scheme. Is everyone else also? In the end, I just want two things: - As a library author I want to be able to freely change my interface around without having to fear tons of programs breaking. Of course interface stability is good, but not everyone has an Architecture Review Board behind them that makes sure the interface actually makes sense. If I discover that it doesn't, I want to be able to change it, not stagnate on the old crud because of backwards-compatibility. - As a user, I just want cabal-install to work reliably. That can only happen if incompatibility is somehow avoided. Let's note that one solution lingering around is the Debian-like stable/testing/unstable model, i.e. every new package would go into unstable, break possibly tons of stuff there, which possibly tons of people will have to fix up, taking considerable time. Some things might not get fixed at all -> old programs become unusable. After some time things would propagate to testing, hopefully not breaking too much, and finally appear in stable in all their glory. The (IMHO) undesirable consequence of this would be, however, that you would get the Debian-like tradeoff between stability and having access to the latest developments. With the ability to declare your incompatibility, ideally combined with some automatic checks, unstable could be removed. We might still want to have testing because you never know, though. -Sven