Any plan for http4s 1.0.0(-M**) series support?

[i10416]

I got the following error when I use http4s-jwt-auth with http4s 1.0.0-M38. Is there any plan for http4s 1.0.0 series?

Exception in thread "main" java.lang.AbstractMethodError: Receiver class dev.profunktor.auth.JwtAuthMiddleware$$anon$1 does not define or inherit an implementation of the resolved method 'abstract void org$http4s$dsl$Http4sDsl2$_setter_$$minus$greater$greater_$eq(org.http4s.dsl.impl.$minus$greater$greater$)' of interface org.http4s.dsl.Http4sDsl2.
        at org.http4s.dsl.Http4sDsl2.$init$(Http4sDsl.scala:31)
        at dev.profunktor.auth.JwtAuthMiddleware$$anon$1.<init>(middleware.scala:24)
        at dev.profunktor.auth.JwtAuthMiddleware$.apply(middleware.scala:24)
        at jtw$package$.<clinit>(jtw.scala:29)
        at run.main(jtw.scala:43)

[froth]

Thanks for the report, I can reproduce this. The problem is, that http4s 0.23.x and 1.X are binary incompatible (which sbt rightfully complains about in my case).

But it seems to be source compatible (I updated http4s-jwt-auth to http4s 1.0.0-M38 and published locally and it works as dependency for a 1.0.0-M38 http4s project). You could to so yourself for a quick local solution, if you want.

Maybe we could create a separate branch for the 1.0.0 series of http4s and publish artifacts for that ( series/2.x ?). What is your opinion @gvolpe ?

[gvolpe]

@froth if you're up for maintaining two different branches, go for it. I don't want anything to do with the maintenance burden.

Otherwise, I'd say we should just bump the version to support the latest milestone and make another release (meaning v1.2.0 is the latest for 0.23.x).

[froth]

Otherwise, I'd say we should just bump the version to support the latest milestone and make another release (meaning v1.2.0 is the latest for 0.23.x).

0.23.x is the latest stable and 1.X is still in development. Therefore I would not like to do that, as it would mean dropping support for the stable http4s version I use in production ;)

@froth if you're up for maintaining two different branches, go for it. I don't want anything to do with the maintenance burden.

I too don't particularly like the idea of maintaining two branches, when I think more about it. Maybe we will have to do so eventually if 1.X becomes stable in the future. But doing so for an extended period of time is not very appealing. Plus it does not seem that an 1.0.0 stable release is around the corner.

@i10416 I think we will support http4s 1.0.0 when it is finally released, or a release date is set (as I intend to use it when its stable ;) ) but for now a locally published version or a fork for 1.0.0-MX is what you can do. I hope this is OK for you at this point in time.

[i10416]

Yes, I looked through implementation and it was not too large to extract core logic from there.

[i10416]

Thanks.