[RFC] "http-types" breakage / additions / rework

BurningWitness:

Vlix:

[Major-major version bump] will break every package that doesn’t have an upper bound

viktor:

it is not clear that the small improvement is justified by the cost it might impose on all the users

simonmic:

it sounds disruptive enough that a new package, perhaps with a similar name, is justified/needed.

What’s the point of versioning then?

I have a section in IPP about this. I think the short answer is, “because the most popular compiler, GHC, only wants you to expose one version of a package at a time when doing a compile”, which makes it really hard to smoothly transition from one version to another, due to the mutual exclusion. I’m fairly confident that it’s this small tooling problem at the foundation of the stack that has caused huge ripple effects in the ecosystem that rests above it.

To be clear:

• You can’t use both versions of a library at the same time from one package, therefore you can’t implement migration path code between the two.
• You’re therefore forced to move along with the ecosystem at the pace set by your dependencies, meaning your upper bounds don’t save you from having to upgrade. Libraries “leak” their dependencies onto you.

I think we could extend GHC’s PackageImports (or add a new extension) to be able to specify major versions and that would let GHC expose multiple versions of a package at once. The lucid/lucid2 experiment is concluded, but in one case I wrote a simple adapter from lucid2 to lucid1 for Yesod by trivially importing both in one module. The concept works. But I haven’t explored this as an RFC.

EDIT: Haskell’s ecosystem is not the frenetic juggernaut that it was in the 2010s, and seemingly the modern community has a substantial number of LLM users for whom updating code due to a breaking change is deemed cheap, so, many things have changed since I wrote my IPP post.