Dependencies/backwards compatibility in Hackage

[Sven Moritz Hallberg]

Björn Bringert <bringert at cs.chalmers.se>, 2007-02-01 16.49 +0100:
> >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