While it is PVP compliant, it would also tie the hands of the developers enough that I don't see many developers wanting to adopt it. Working across multiple packages means very painful changes to your build process if you don't use cabal install for everything. It is even rather painful if you do use cabal install for everything.

A slightly more palatable PVP compliant version which burns through version numbers much faster is to separate the two digits of the major version and use one for .Internal changes and one for changes to the majority of the public API. Then users who only use the public API can depend on the first digit. However, this has awkward aesthetics as your version numbers start skyrocketing.

I'm not a fan of either approach.

-Edward

On Mon, Oct 7, 2013 at 10:35 AM, Henning Thielemann <lemming@henning-thielemann.de> wrote:

On Mon, 7 Oct 2013, Edward Kmett wrote:

A rule of thumb that has served me well w.r.t exposing internal modules is to expose a Data.Foo.Internal but
make it clear it is a very fragile interface.
Even by going to far as to say this module does not follow the PVP and that they should expect breaking
changes to come fast and often. Users should only safely depend on it with minor-version specific bounds
then. This ameliorates the concerns about how it ties your hands as an implementor.

A PVP compliant solution would be to divide 'containers' into 'containers-internal' and 'containers'. The new package 'containers-internal' exposes internal data structures, but increases version numbers at a higher rate than 'containers'. The package 'containers' would only expose the public API and thus a more stable interface.