Release v6.0.0

[ixti]

No description provided.

[ixti]

@tarcieri if that looks good to you - I will cut the release

[tarcieri]

Are there actually any breaking changes?

[ixti]

I believe #776 and #783 are.

Also, I just noticed a PR that I wanted to merge 4 years ago and never get to it, that I believe we should add in the release. The change will be in how readpartial work to make it more IO-alike (raising EOFError when the end is reached instead of silent empty chunk). See: #618

[ixti]

Alternative - I can cherry pick retriable and headers caching and cut 5.3.0 release instead.

[tarcieri]

I’d definitely like to roll forward rather than backward, but v6.0.0 would be a great time to update the timeout subsystem: #773

[ixti]

Will merge #773

[tarcieri]

#773 is an issue, not a PR. Perhaps we should ping the people mentioned in that issue to see if they can open a PR, though

[ixti]

Oh, I have confused it with #754 indeed

[tarcieri]

I made a last call for breaking changes to the timeout subsystem in #773, though perhaps we should merge #754 first as well

[loflofloflof]

Hey @ixti! 👋

I maintain the Peddler gem (Amazon SP-API client) and we'd love to use the :raise_error feature from #792 for our error handling. It's exactly what we need!

Since v6.0.0 seems blocked on breaking changes, would you consider that v5.3.0 release you mentioned in August? Cherry-picking the raise_error feature (plus retriable/headers caching) would help us and other downstream libraries adopt it immediately rather than waiting for v6.0.0.

Thanks for all the great work on HTTP! 🙏

[ixti]

After looking through the changes, I think it's fine to release 5.3.0 off the master by only excluding 1ba37c2, the rest looks fine for minor version bump. Doing that now

[ixti]

Released v5.3.0; Closing this ticket, as I agree we should add as many breaking changes as we can to avoid making major bumps a habbit ;D

[ixti]

Here's the list of backported commits: v5.2.0...v5.3.0

[sferik]

@tarcieri @ixti How about now?

I’ve gotten the number of open issues down to 25, none of which are labeled as bugs. All of the issues in the v6.0.0 milestone are closed. Of the remaining open feature/enhancement requests, I believe most of those can be added without making breaking API changes, so they can be added over time in 6.1, 6.2, etc.

Please review the CHANGELOG.md to see everything that’s changed since the v5.3.1 release. There are several breaking API changes. For most of those, I opened pull requests and waiting for at least one of you to approve them before merging, but I’d appreciate another review of those changes, in particular, since API churn is more work for end users.

@ixti Do you want to rebase this branch to bump the version to 6.0.0 and make any other changes you’d like before the release? I’d love to ship v6.0.0 in the coming week, if possible, but please let me know if you need more time to review these changes.

[tarcieri]

I’m happy to leave it at your discretion and glad to see it’s being maintained

[sferik]

To prepare for the v6.0.0 release, I’ve:

• Closed the v6.0.0 milestone.
• Opened a v6.1.0 milestone for v6.0.0-compatible changes.
• Open a v7.0.0 milestone for v6.0.0-incompatible (i.e. breaking) changes.
• Added an UPGRADING doc that provides concrete examples of all breaking changes in v6.0.0 and how to resolve them, which I think is clearer than just reading the CHANGELOG.

Before the release:

• I’d like to get to a decision on New feature: Acceptable #791. I’ve expressed my opinions in the comments.
• I just noticed that we added a conditional to the gemspec in Native llhttp for MRI #800. I don’t believe this will work as intended. The gemspec is only evaluated once, at gem build time, not at install time. The resulting dependency metadata is baked into the gem package. If I build a v6.0.0 gem on MRI, RUBY_ENGINE == "ruby" will be true, so the resulting gem will always declare a dependency on llhttp and never on llhttp-ffi. JRuby/TruffleRuby users installing the published gem will get llhttp, which won't work for them. To actually ship platform-specific dependencies, we need to build and publish platform-specific variants (e.g., http-6.0.0.gem and http-6.0.0-java.gem). I’ll work on a patch that fixes this now. What I’d actually like to do is set up trusted publishing for the gem, so that it builds and pushes both variants from a GitHub action. I’ll also add JRuby to the CI matrix.
• There’s also Specific ordering of duplicate key names for multipart data. #663, which will require a release of http-form_data. @ixti can you get Support duplicate form names in multipart forms form_data#32 over the finish line? I’d like to do a bit of cleanup on that gem as well before we ship it. Can you give me gem push access so I can set up trusted publishing for http-form_data?