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

Unless you plan to provide full compatibility story (i.e. existing packages will continue to compile with newer version with deprecation warnings indefinitely), this is going to result in horrible breakage across the ecosystem.

http-types has 986 direct dependencies on Hackage. How many of them have loose bounds and are going to require revisions? Who’s going to spend time making these revisions?

But this isn’t even the biggest problem here, because making revision can be probably automated to some extent. The biggest problem is that if you break API, then for people to use packages in their application/library that depend on http-types either all of them need to compile with the old http-types or all of them need to compile with the new http-types.

This is practice means tons of work/coordination/forking if anyone would want to migrate their dependencies to new http-types and not all packages they depend on have migrated.

Now, what is one of the reasons someone would like to do this, perhaps even urgently? Security vulnerabilities (which are likely to be discovered in packages that use the network, especially nowadays that LLMs are already quite good at finding these holes for you and will only get better).

A smaller version of this phenomenon already happened with crypton and its move from memory to ram in tandem with Haskell Security advisories.

Do you want to fix this vulnerability in your application? All your dependencies need to work with crypton that uses ram. They don’t (like e.g. amazonka)? Oh well, forking time!

And crypton has “only” 109 direct dependencies, so it’s 9 times less dependencies to worry about.