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