nhooyr
v1.8.8
Unfortunately going to have to delay this. The autobahn test suite is failing.
A slight adjustment to the "wip" commit here and the test suite all seems to run. It would be really good to get this unblocked as there are bunch of PRs that are dependent on it too.
Awesome good to know @tomqwpl
What did you change and how did you run the test suite? Are you positive you ran the autobahn tests? I believe there's an env variable to make them run.
My house burned down a few weeks ago and so did my vehicle so I'm in a bit of a rough spot right now. So unfortunately I won't get to this for another while :(
Got the autobahn tests running. Looks like the section 12 compression tests are failing. Should have it fixed this week.
Ok so tests pass now and the dev branch is merged with master.
Now I need to fix CI, review code and then go through issues/PRs to find any last minute merges before v1.8.8. Aiming to release next week.
Ok code wise this is ready, Now for updating any out of date docs, reviewing and then writing the changelog.
Will definitely be out by Friday evening <3
Thanks for the patience everyone.
Wow, big PR! Looking forward to the update, thanks.
I’m curious why the bump is to go 1.19? We are currently at 1.21. I thought 1.20 would be a minimum. Golang only continues support for the latest 3 versions, it’s going to seem like 1.19 is EOL in a blink of an eye.
Would be great to get some info on the state of compression in the docs update too. It seems there were some issues with safari? There also used to be some memory estimates for sliding, but they seemed to vary quite a bit. I also noted the third party compression library is removed. I’m a bit lost on the compression features now.
I’m curious why the bump is to go 1.19? We are currently at 1.21. I thought 1.20 would be a minimum. Golang only continues support for the latest 3 versions, it’s going to seem like 1.19 is EOL in a blink of an eye.
No features I need from Go 1.20 as of now so I figured no reason to bump the version. Can always bump later if necessary.
Would be great to get some info on the state of compression in the docs update too. It seems there were some issues with safari? There also used to be some memory estimates for sliding, but they seemed to vary quite a bit. I also noted the third party compression library is removed. I’m a bit lost on the compression features now.
The issues were with Safari itself and not the library. So I've removed compression support for Safari by removing the compatibility layer for x-webkit-deflate-frame. Safari does not implement the standardized permessage-deflate extension. I will remember to make note of this in the release notes thanks for reminding me.
There also used to be some memory estimates for sliding, but they seemed to vary quite a bit. I also noted the third party compression library is removed. I’m a bit lost on the compression features now.
Yup no third party compression library anymore. I don't think it's worth adding an extra dependency even if it is faster. Eventually klauspost's compression improvements will make it to the stdlib. In regards to the memory usage estimates, they are now:
context: fixed 32 KB sliding window + fixed 1.2 MB flate.Writer + pooled 40 MB flate.Reader
no context: pooled 1.2 MB flate.Writer + pooled 40 MB flate.Reader
I would not enable compression without benchmarking for your particular use case and confirming it's the right decision.
Release notes are complete. Docs have been updated. Will release Friday at noon.