Versioning scheme?

[armanbilge]

Considering that:

1. these modules depend on http4s 1.0 milestones
2. they're been previously published under those versions

[rossabaker]

I would start at 1.0.0-M28 (I'm staging 1.0.0-M27). It may drift from core, but they should probably hit 1.0.0 at the same time.

[armanbilge]

Are there no plans for something between 0.23 and 1.0? I.e. a pre-1.0 stable release with Scala.js support?

[rossabaker]

I would prefer to keep pressing forward for a 1.0. Every stable release is something that needs support if "stable" is to mean anything. I have spent a full work day, with overtime, trying to release a patch across four branches. My work, and the vast majority of our downloads, are still on 0.21, which we've stopped supporting with features but would be reckless to leave. The idea of a fifth branch makes me want to throw my computer into the creek, and I'll soon be opening a discussion about how we wind the oldest ones down.

We are finally in an era that we are not chasing Scalaz -> Cats, or Scalaz-Stream -> multiple versions of FS2, or Scalaz-Task -> FS2 Task -> multiple versions of Cats-Effect, or breaking changes in Scala itself. It's the most stable foundation we've had in our eight years, and if we can't make a hard push for 1.0 now, I really don't know when.

[armanbilge]

Thanks for the explanation and perspective. Really helpful to know where to direct my momentum :)

[rossabaker]

Keep in mind that with a stable core, client, and server, most other modules will float into their own repos like this, and have a lot less pressure.

I want to spend more quality time with the HTTP semantics draft, which describes a core that works on HTTP/1, HTTP/2, and HTTP/3. We're old enough we developed a lot against an obsolete RFC, and we'll be well placed for the future when we fully syncrhonize with that.

[armanbilge]

Established in #11 (comment).