Uncouple the pom from http4s

[bryce-anderson]

With http4s gaining momentum and a lot of bug fix releases on the horizon, it should start maintaining binary compatibility between bugfix releases. That means that if rho wants to get those fixes 'for free' and not need to do a lockstep release with every http4s bugfix, we should think about decoupling the pom from http4s. That will mean that users will need to specify http4s explicitly, but thats already a given considering they will need a backend.

[arouel]

I agree and also using it that way. Would it be good to propose this in our README?

[bryce-anderson]

Oh for sure. We should also start keeping a changelog.

On Wed, Nov 26, 2014 at 3:01 PM, André Rouél notifications@github.com
wrote:

I agree and also using it that way. Would it be good to propose this in
our README?

—
Reply to this email directly or view it on GitHub
#44 (comment).

[rossabaker]

What does decoupling mean? You're still going to need a version to compile against, unless you're putting http4s-server into provided scope?

[bryce-anderson]

Yes, I believe that is the procedure.

[arouel]

So we would recommend users of Rho to manage http4s dependencies independently to pull in bugfix releases easily, right?

[bryce-anderson]

Yes, but they have to do this now anyway because they have to specify a backend unless they are just building an abstract rho service, then they will need to bring in http4s-server % "provided". So, for the most part, when a user specifies the http4s-blaze or http4s-servlet dependency they will need to run, http4s-server will be brought along for the ride.

The best part is getting the bugfixes for free, so long as we can keep them binary compatible.

[arouel]

agreed