"Claus Reinke" <[EMAIL PROTECTED]> writes: > if that is your definition of compatible, you can never throw any > packages away
Is this a problem? > alternatively, it would require perpetual updates of dependencies in > package descriptions, which we'd like to avoid, right? I think the whole point of all this is that a package that used to work should continue to work without modification, as long as its dependencies are satisfied. > - consider [..] All this complexity seems to arise from the perceived need to be able to fulfil dependencies from other packages than the specified ones. Isn't it just much easier to keep old versions around? Isn't this what everybody else does - e.g. using branches in the VC or similar? Branching support in the build system sounds like entirely the wrong approach to me. (Or am I just misunderstanding completely?) >> A client of an API can be tolerant to certain changes in the API, >> but that is something that the client knows about, not the provider. > that is the very issue i'd like to see reversed. > you're right the first time round: when the client is first written, > it is the client's responsibility to specify a useable dependency > version; but keeping the responsibility this way round causes nothing > but trouble after the client has been released, if its dependencies > develop faster than the client Yes. > so, i'd like to see two stages, before and after publishing: > 1. author of client package specifies precise dependencies > 2. users of client packages can continue using it unchanged > even if its dependencies move on > one way to assure 2 is to keep all old package versions > around forever somewhere (we can't do a whole-web garbage collection, > so we never know when there are no more pointers). Sounds good to me. If you're careful about tagging your darcs repos, any trunk version (including common bugfixes) should be extractable. > another way is to allow authors of package dependencies > to take on part of the burden, thereby helping to reduce > breakage and garbage for their clients. so the authors of mtl-9.0 > could note that it still provides all the modules of earlier versions, I'm still at a loss as to why they could not name it mtl-8.n+1 instead. And if there's a good answer to that, why they couldn't just have two separate cabal files in their distribution and some hackery to build and install either or both of 8.n+1 and 9.0. What happens when the branches diverge, say there's a bugfix that only applies to 8.x? > so the package manage would only have to keep the latest version > around, and clients of earlier versions would not notice any breakage. So the trade off is some disk space versus a more complicated build system and possibly more manual intervention? Not that I don't have faith in maintainers' interest and capability of precisely specifying compatibility issues in the libraries they develop, but for an old bit-rotted application, I'm fairly sure the safest thing is to build against the libraries it was written against -- or at a branch of same with as few non-bugfix modifications as possible. -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
