Upgrading to 4.x strategy
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- erlang
- Lĩnh vực
- networking
Hướng nghiên cứu
Không có tệp, bài kiểm thử hoặc điểm vào nào được nêu tên. Hãy bắt đầu bằng việc xem xét thay đổi phá vỡ API của Hackney 4.x và xác định bề mặt API cũ được các thư viện phụ thuộc sử dụng. Công việc được xem là hoàn tất khi đã thống nhất chiến lược di chuyển, bao gồm việc xác định liệu một lớp tương thích hackney_old tạm thời có khả thi hay không.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Erlang
- Star
- 1.4k
- Fork
- 458
- Merge trung bình
- 11 giờ 32 phút
- Pull request đã merge (30 ngày)
- 47
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của benoitc/hackney
-
Support Certifi 2.19.xĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Implement HTTP QUERY (RFC 10008)Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
Maintainer thường phản hồi trong vòng 1 ngày
-
keepalive timer also closes a freshly dialed pooled connection during the HTTP/1.1 TLS upgradeĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 58/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
feature
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
benoitc/hackney#596 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của benoitc/hackney
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue severity: low tech-debt
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 75/100
TMHSDigital/subenum#329 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Backblaze/b2-sdk-java#247 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
steelbrain/node-ssh#487 ·