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 <[EMAIL PROTECTED]> wrote:
Björn Bringert wrote: > Sven Moritz Hallberg wrote: >> Björn Bringert <[EMAIL PROTECTED]>, 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 [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
_______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
