Upgrading to 4.x strategy
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- erlang
- Área
- networking
Línea de trabajo
No se nombran archivos, pruebas ni puntos de entrada. Comienza revisando la ruptura de la API de Hackney 4.x e identificando la superficie de la API antigua utilizada por las bibliotecas dependientes. Se considerará terminado cuando exista una estrategia de migración acordada, incluida la determinación de si es viable una capa de compatibilidad temporal hackney_old.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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_old compatibility 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
- Lenguaje dominante
- Erlang
- Estrellas
- 1.4k
- Forks
- 458
- Merge medio
- 11 h 32 min
- PR fusionados (30 d)
- 47
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de benoitc/hackney
-
Support Certifi 2.19.xAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Implement HTTP QUERY (RFC 10008)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
-
keepalive timer also closes a freshly dialed pooled connection during the HTTP/1.1 TLS upgradeAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 58/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
feature
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
benoitc/hackney#596 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de benoitc/hackney
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
good first issue severity: low tech-debt
Dificultad 2/5 Medio día Aptitud para principiantes 75/100
TMHSDigital/subenum#329 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Backblaze/b2-sdk-java#247 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
steelbrain/node-ssh#487 ·