<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 6:55 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michael,<br>
<br>
I'm supportive of this (just as I've been in the past). We need to<br>
have network-uri added to the HP, which I don't think should be a<br>
problem as the API doesn't change with this split, assuming that the<br>
new maintainer agrees to follow the HP rules (e.g. don't add non-HP<br>
packages as dependencies, don't radical change the API without<br>
discussion.)<br>
<br>
I have a slight preference to use 2.6 as the network version number,<br>
as I'm saving 3.0 for something more juicy.<br>
<div class=""><br></div></blockquote><div><br></div><div>I have no objection to 2.6 instead of 3.0. I didn't feel strongly one way or the other, I just wanted to make the proposal as concrete as possible. Consider it amended to use 2.6 instead.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> 1. Create a new package, network-uri, version 2.5.0.0, which exposes no modules and has an upper bound `network < 2.6.<br>
<br>
</div>I'm sure there's something clever behind this empty package, but I<br>
don't quite understand it. How does this help. Note that depending on<br>
network-uri but not network will not let you use Network.URI in your<br>
code, as that module will be hidden.<br>
<div class=""><br></div></blockquote><div><br></div><div>The idea is that users of Network.URI will be able to add a dependency along the lines of:<br><br></div><div>    build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7<br>

<br></div><div>and work with both the pre- and post-split versions of the package, without any conditional compilation or cabal flags. I'm sensitive to adding any requirements of cabal flags, since (1) it clutters cabal files quite a bit[1], and (2) we just went through some painful cabal-install dependency solver issues around flags.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> 2. Create a second release of network-uri, version 3.0.0.0, which provides the Network.URI module verbatim as provided by the network package today, and has a lower bound `network >= 3.0`.<br>
<br>
</div>(And < X+1, as the HP follows the PVP.)<br>
</blockquote></div><br></div><div class="gmail_extra">I really don't want this to turn into another PVP discussion. And I'm not going to object to including an upper bound here if that's deemed "required" for some reason (I only left it out of the proposal since it's irrelevant to my point). All that said...<br>

<br></div><div class="gmail_extra">Can you name a single way in which an upper bound *actually* helps? network-uri will not depend on any functionality in network itself[2], so there's no way that a breaking change in network will possibly cause network-uri to stop compiling. The *only* possibility is that network could expose a module that conflicts with a module in network-uri. However:<br>

<br></div><div class="gmail_extra">1. That is not a protected situation by the PVP anyway; adding a new module to a package is a minor version bump, so an upper bound wouldn't provide protection.<br></div><div class="gmail_extra">

2. I actually think we *should* have a guarantee that network never expose a module that conflicts with network-uri. Better yet, I think there should be an accepted standard that no two Haskell Platform packages export the same module name. (I'm not actually proposing that here, it's clearly separate than my main proposal.)<br>

<br></div><div class="gmail_extra">So if someone can articulate a good reason for an upper bound in network-uri on network, please let me know. Again, if this is going to end up blocking this proposal, I'd rather just include the upper bound.<br>

<br></div><div class="gmail_extra">Michael<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] Two painful experiences for me were the network + network-bytestring merge, and the blaze-html/blaze-markdown split. I'd like to try to avoid that situation, and in my recent package merging, I've done so as much as possible.<br>

</div><div class="gmail_extra">[2] If there *is* some dependency from the Network.URI module to the rest of the network package, please let me know, I couldn't see one.<br></div></div>