2.0.0 changelog

[lpinca]

The release is not ready yet but I spent some time writing a changelog with the changes up until now. Here it is:

Breaking changes

• Dropped support for Node.js < 4.
• The new operator is now required to create all instances as we moved to ES6
  classes.
• Error messages have been simplified.
• The clients property of the WebSocketServer is no longer an Array but a
  Set and is only set if the clientTracking option is truthy (Use a set instead of an array to track clients #806).
• The default HTTP status message is now used when handshake fails (41e7cae).
• Removed support for the Hixie-76 version of the protocol (Drop support for Hixie-76 #871).
• Removed ability to specify different paths for multiple WebSocketServers
  when binding them to the same underlying HTTP/s server (Remove path registry #885).
• Removed WebSocket.prototype.stream() and ability to pass a readable stream
  to WebSocket.prototype.send() (Remove stream method and ability to send a stream #875).
• Removed callback argument from handleProtocols handler (Remove callback from handleProtocols #890).
• Removed supports property from WebSocket (Remove supports attribute #918).
• Removed WebSocket.createServer(), WebSocket.createConnection(), and
  WebSocket.connect() factory functions (Remove WebSocket.createServer() and WebSocket.connect() #926).

The following breaking changes only apply if you required the mentioned classes
directly.

• Removed Sender inheritance from EventEmitter (Remove Sender inheritance from EventEmitter #861).
• Removed BufferPool class (73ab370).
• Made extensions a required argument for the Receiver constructor (5f53194).

Features

• Added ability to set TCP backlog for WebSocketServer (Allow 'backlog' option for listening socket #795).
• Added checkServerIdentity option to WebSocket (Added checkServerIdentity option to WebSocket #701).
• Added a threshold option for permessage-deflate to only compress messages
  whose size is bigger than threshold (6b3904b).
• Added shouldHandle method to WebSocketServer to see if a request should
  be accepted or rejected. This method can be overridden by the user if a
  custom logic is desired (6472425).
• Added removeEventListener method to WebSocket (078e96a).

Bug fixes

• Fixed an issue that prevented permessage-deflate options from being correctly
  handled (fix PerMessageDeflate options pass issue #744).
• All error events are now emitted with a proper Error instance (Make sure that no string is emitted as an error #789).
• Fixed an issue that could cause a stack overflow crash (Fix stack overflow crash #810).
• Added 1012 and 1013 to the list of allowed close codes (b58f688).
• Fixed an issue that prevented the connection from being closed when path
  validation failed (Issue path validation #534).
• Fixed an issue where the fin option of WebSocket.prototype.send() was
  unconditionally set to true (ea50be7).
• Fixed an issue that prevented the total length of a fragmented message from
  being correctly calculated (545635d).
• Fixed an issue where zlib.flush() was called with a wrong flush level
  (Permessage-deflate calls zlib flush with wrong flush level #733).
• The callback of WebSocketServer.prototype.close() is now invoked when the
  close event is emitted by the underlying HTTP/s server (Invoke the close callback when the close event is emitted #892).
• Fixed an issue that prevented the server from listening on IPv6 addresses
  with default settings (dcdc652).
• Fixed an issue where the connection event was emitted even if the client
  closed the connection during the handshake process (04530ad).
• The masking key is now generated using crypto.randomBytes() instead of
  Math.random() (7253f06).

Can a native speaker take a look and check if my Itanglish is ok or if there is something that is not clear enough?

Thanks!

[Nibbler999]

There are some typos, but looks good otherwise:

checkServerIdentify should be checkServerIdentity
unconditinally should be unconditionally

[lpinca]

Saved as draft under https://github.com/websockets/ws/releases, closing.

[erikpukinskis]

Disappointing to see you drop Node support! Won't be able to continue on in the 2.0 branch I suppose. Care too much about the installed base. ES6 continues to infect otherwise good projects.

[lpinca]

@erikpukinskis you can fork and transpile via babel if you care about Node.js < 4.

[erikpukinskis]

@lpinca That's a great idea! I hadn't thought of that. I'm just going to stay on the 1.0 branch for now, but yours is one of the (extremely) few low level libraries I rely on so I may eventually look into transpiling.

Thanks for your hard work. I think ES6 has destroyed the most powerful aspects of Javascript (simple build tools, ubiquitous runtime, small language) so I am very frustrated with module authors requiring the new heavier build architecture. If my comment seemed aggressive it's just that frustration coming out. ES6 is infecting the entire JavaScript world making it increasingly difficult to run true JavaScript applications.

But I really appreciate the time you've put into this module it is excellent.

Is there any plan for maintenance of the 1.0 branch? What would be a good place to watch for discussions of security updates?

[lpinca]

If my comment seemed aggressive it's just that frustration coming out. ES6 is infecting the entire JavaScript world making it increasingly difficult to run JavaScript software. It's frustrating to have module authors over and over drop their support for JavaScript.

No problem, I understand and I partially agree but wanted or not ES6+ is the future and some features were really needed imo :)

Is there any plan for maintenance of the 1.0 branch?

I don't think so as I don't want to bang on the 1.0 drums any longer but other collaborators might disagree with me and come up with a plan to backport bug and security fixes to the 1.0 branch.

Thanks for sharing your opinion!