Platform policy question: API compatability in minor releases
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Sat May 9 20:57:22 EDT 2009
On Sat, 2009-05-09 at 16:29 -0600, Denis Bueno wrote:
> On Sat, May 9, 2009 at 12:50, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> > Allow compatible API additions
> >
> > If the change is compatible then it does not break any existing
> > programs, so it should be allowed. Any program that works with a
> > platform particular release will continue to work with
> > subsequent minor versions. This is standard backwards
> > compatibility policy.
>
> Isn't this false, though? Some existing program could easily break.
>
> Suppose a library exports functions f and g, but in the next minor
> revision starts exporting h. Some code that uses the library uses f
> and g, and defines its own (unrelated) function called h in the module
> that imports the library unqualified. When the library gets updated,
> the code now has an ambiguous reference to h.
>
> Please correct me if I'm wrong.
You're not wrong. The PVP operates under the assumption that client code
that depends on a package that follows the PVP will use qualified or
explicit imports.
http://www.haskell.org/haskellwiki/Package_versioning_policy
If anything, your point is an argument that we should not allow
"compatible" changes because although we can expect people uploading
packages to Hackage to understand the versioning policy of packages that
their own package depends on, the same is not necessarily true of all
users for all programs. The platform has a wider remit in this case as
it is intended to serve as the library basis for most real world Haskell
code.
Duncan
More information about the Libraries
mailing list