[Haskell-cafe] Checking in packages to Hackage early in development cycle?

[Duncan Coutts]

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