"Claus Reinke" <[EMAIL PROTECTED]> writes: > if this is the "official" interpretation of cabal package version numbers, > could it please be made explicit in a prominent position in the cabal docs?
Me too. This is not a criticism nor endorsement of any particular scheme, just a vote in favor of having a - one, single, universal - scheme. > of course, i have absolutely no idea how to write stable packages under > this interpretation. and the examples in the cabal docs do not explain this, > either (neither "bar" nor "foo > 1.2" are any good under this interpretation). You need a way to specify "foo > 1.2 && foo < 2", which is a suggestion that was tossed around here recently. Also, you'd need foo 1.x for x>=2 to be available after foo-2.0 arrives. 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. The major/minor scheme has worked nicely for .so for ages. I'd like to make the additional suggestion that a major version number of 0 means no compatibility guarantees. >> Another reason not to change the name of 'base' is that there would >> be a significant cost to doing so: the name is everywhere, not just >> in the source code of GHC and its tools, but wiki pages, >> documentation, and so on. Much like 'fps', now known as 'bytestring', no? I had some problems finding it, true, but the upside is that old stuff is free to reference fps until I can get around to test and update things. > how about using a provides/expects system instead of betting on > version numbers? if a package X expects the functionality of base-1.0, > cabal would go looking not for packages that happen to share the name, > but for packages that provide the functionality. base-not-1.0 would > know that it doesn't do that. and if there is no single package that > reexports the functionality of base-1.0, cabal could even try to consult > multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? -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