Repository navigation
Upgrading to 4.x strategy #907
Description
Activity
well it's a major version. I made sure to not break versionning. Also there wasn't that much changes and were documented there: https://hackney.hexdocs.pm/migration.html
For which version would you want this compatibility layer ?
One of the parts of Hackney that changed dramatically is connection pooling. In 1.X.X a pool effectively meant a maximum number of concurrent connections/requests per some purpose (media download, data propagation,...). In >=2.X.X it is no longer the case, and now if I read the documentation right, it is maximum number of connections per host. It is no longer "I want to send at most X requests at the same time for this purpose", but "I want to send at most X requests at the same time to this host for this purpose".
The previous behavior was useful for one request to many hosts (data propagation), the current one is instead useful for many requests to a handful of hosts. As far as I understand, there is currently no way to emulate the 1.X.X behavior in 4.X.X.
Hello,
I find upgrading to 4.x quite challenging. Many dependencies still rely on Hackney versions prior to 4.x, which means we have to fork each of them, investigate exactly which parts of the old API they use, and migrate them to the new interface.
This is a significant backward compatibility break. It seems it could have been made much easier by providing a temporary
hackney_oldcompatibility layer that emulates the previous API, allowing existing projects to migrate incrementally instead of requiring all dependent libraries to be updated at once.There are probably thousands of projects on GitHub that depend on Hackney, and some of them have little or no ongoing maintenance. In those cases, users are effectively forced to fork the projects themselves just to make them compatible with Hackney 4.x, even if the libraries only use a small subset of the old API.
Silviu