Dependencies/backwards compatibility in Hackage

[Neil Mitchell]

Hi

We're all assuming here that HaXml deliberately decided to change the
interface. Is that really true? (only Malcolm can answer)

Most of the time I guess that the interface will change by accident,
without people spotting. Perhaps we are trying to solve the wrong
problem...

Thanks

Neil

On 2/1/07, Björn Bringert <bringert at cs.chalmers.se> wrote:
> Björn Bringert wrote:
> > Sven Moritz Hallberg wrote:
> >> Björn Bringert <bringert at cs.chalmers.se>, 2007-02-01 15.36 +0100:
> >>> Ross Paterson wrote:
> >>> I think that the correct solution to this problem would be to make a
> >>> new release of haxr (which used to be XmlRpc) that works with HaXml
> >>> 1.17.
> >>
> >> 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 :-).
> >
> > 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.
>
> Eh that is what Ross already said. Sorry about that. This is the
> approach taken by Unix shared libraries by the way.
>
> /Björn
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>