On Fri, 2009-03-20 at 10:39 +0000, Colin Paul Adams wrote: > Duncan> We call it the Package versioning policy (PVP) > > Duncan> http://www.haskell.org/haskellwiki/Package_versioning_policy > > Duncan> Package authors are encouraged but not required to follow > Duncan> it. In the not too distant future you will be able to > Duncan> explicitly opt-in, in which case we will try to check that > Duncan> the package does indeed follow the policy and advising > Duncan> authors of dependent packages about the kind of version > Duncan> constraints they should use. > > I missed the upper bounds on dependencies. How am I supposed to know > what the upper bound is?
If your packages depends on a package that follows the PVP then the upper bound is +0.1 than the latest version you know your package works with. For example suppose you need the zlib package. Suppose the minimum version you need is 0.4. Suppose that you tested it with version 0.5 and you were lucky at the bits of the API that changed were not the bits you were using. Then you would say: build-depends: zlib >= 0.4 && < 0.6 It's < 0.6 because that is the next breaking API version. If the next zlib release is compatible then it'd be something like 0.5.1.0 or 0.5.0.1. However zlib-0.6 would be a new version that breaks existing APIs. Since you have no idea which APIs I'm going to break when I release zlib-0.6 then you should play it safe and require any 0.5.x version but not 0.6. Make sense? This is why we need the PVP. Without it (or something similar) we cannot know what the right upper bound is. Putting in sensible upper bounds will make hackage much more reliable and less prone to breakage as new packages are released. It is definitely something we're trying to encourage (and something that needs tool support). Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
