Proposal: Partitionable goes somewhere + containers instances

[Edward Kmett]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131007/7fd5ceda/attachment-0001.html>