On Thu, Jan 31, 2013 at 3:28 PM, Herbert Valerio Riedel <hvr@gnu.org> wrote:

Michael Snoyman <michael@snoyman.com> writes:

[...]

> * Release a new version of network (1.5) that does not include the
> Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
> * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
> * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

Alas, this causes some of the conditional-API issues mentioned in [1],
specifically the following situation:

Say, I have a package which specifies only its dependancy on
'network-uri' (but not 'network') for its 'Network.URI' module, then the
package compilation breaks depending on the actual version of the
'network' package linked against.

[1]: http://www.haskell.org/pipermail/libraries/2012-November/018750.html

That's true, but I don't think we have *any* means at our disposal of creating a migration plan that has zero impact on users. The reason I suggested my approach is that the only change users would need to make is to add network-uri to their dependency list. You're correct that it's possible that a user could depend exclusively on network-uri and thereby cause trouble for users of the older network package, but I would argue that's an acceptable tradeoff in this case.

Michael