Publish against http4s v0.23.x
armanbilge opened this issue · 4 comments
This is assuming that http4s/http4s#5285 is imminent. I think having a (stable) release against a stable http4s version will be a big deal and help win over some of the naysayers e.g. keynmol/http4s-laminar-stack#7 (comment) 😉
However, this opens a pandora's box of versioning problems (see also #2). I'm also acutely aware of the upcoming scala-js-dom v2.0.0 release, which will hopefully land sometime in October. Unfortunately, I think it's important that we support both while the ecosystem upgrades.
My proposal:
- Start http4s-dom series/0.1 against http4s 0.23.x and scala-js-dom 1.x.
- When scala-js-dom 2.0.0 arrives, start http4s-dom series/0.2.
- Continue publishing 1.0 milestones against http4s 1.0 milestones and scala-js-dom 2.x. If we don't keep our milestone numbers in sync with upstream http4s this will get really confusing, but it also prevents us from releasing on our own cadence. (Would it be weird to have minor milestone releases? e.g.
1.0.0-M28.1) - Pray that there's never a http4s 0.24.x.
Also open for discussion: this would require a commitment of stability for the http4s-dom API itself. Are we ready?
One more thought: right now this repo is 3 separate modules (core, fetch-client, service-worker). Actually this is probably over-engineered and I see no reason not to merge the modules into http4s-dom and be done with it.
I won't say http4s-0.24 happens over my dead body, but I'd have to be very well sedated. The 0.x -> 0.23, 1.x -> 1.x plan sounds good to me.