On 14 December 2005 01:28, Isaac Jones wrote:

"Simon Marlow" writes:

...

I'd be rather happier if we could solve the versioning issue with Cabal, so that upgrading Cabal in the future doesn't automatically break code. It might not be possible to do this the first time around, but now is the time to design our way out of future problems.

We need to experiment with stuff. People want to use the advanced features like hooks on complex packages, but no one wants the cabal-1.0 interface to hooks! We're trying to maintain a tension between experimenting and providing something stabler for simple programs (just like Haskell itself). It's bad if that breaks stuff, but I don't want to end up in a situation where we tie ourselves to a bad implementation because 3 packages used the old interface. I think we just need to be better about explicitly stating what is stable and what is not.

Absolutely, I understand that. I'm not suggesting every tiny revision of the interface must be available for ever. But I think it would help a great deal if a Cabal release could support the previous, say, 1 or 2 major revisions of the interface, just to smooth the transition, so that a new release didn't automatically break a lot of packages. eg. Setup.lhs would do this: import Distribution_1_2.Simple main = defaultMain all we have to do is provide Distribution_1_2.*. When we freeze a version, we create a bunch of stubs under Distribution_<ver>, using explicit export lists everywhere. Sometimes we'll have to add some backwards compatibility code. The latest experimental version of the interface is always available as Distribution.* (or maybe Distribution_cur.*, or something), with appropriate warnings generated by DEPRECATED pragmas that the interface is subject to change. I've been thinking about adding support to Haddock to compare versions of interfaces and tell you what the changes are, this would be great for documentation and also to make sure that we aren't breaking interfaces. Cheers, Simon