cabal release

[Simon Marlow]

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

> "Simon Marlow" <simonmar at microsoft.com> 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