More thorough object cleanup

- Only pass `torrent.infoHash` to the Chunk Store constructor, instead
of the `Torrent`
  instance itself, to prevent accidental memory leaks of the `Torrent`
object by the
  store. (Open an issue if you were using other properties. They can be
re-added.)

- Non-fatal errors with a single torrent will be emitted at
`torrent.on('error')`. You
  should listen to this event. Previously, all torrent errors were also
emitted on
  `client.on('error')` and handling `torrent.on('error')` was optional.
This design is
  better since now it is possible to distinguish between fatal client
errors
  (`client.on('error')`) when the whole client becomes unusable versus
recoverable errors
  where only a single torrent fails (`torrent.on('error')`) but the
client can continue to
  be used. However, if there is no `torrent.on('error')` event, then
the error will be
  forwarded to `client.on('error')`. This prevents crashing the client
when the user
  only has a listener on the client, but it makes it impossible for
them to determine
  a client error versus a torrent error.

- Errors creating a torrent with `client.seed` are now emitted on the
returned `torrent`
  object instead of the client (unless there is no event listeners on
  `torrent.on('error')` as previously discussed). The torrent object is
now also destroyed
  automatically for the user, as was probably expected.

- If `client.get` is passed a `Torrent` instance, it now only returns
it if it is present
  in the client.

1 files changed, 24 insertions, 4 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 9e24ca5..a5a5c07 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -25,16 +25,36 @@
 
 - Deprecate: Do not use `torrent.swarm` anymore. Use `torrent` instead.
 
+- Only pass `torrent.infoHash` to the Chunk Store constructor, instead of the `Torrent`
+  instance itself, to prevent accidental memory leaks of the `Torrent` object by the
+  store. (Open an issue if you were using other properties. They can be re-added.)
+
+- Non-fatal errors with a single torrent will be emitted at `torrent.on('error')`. You
+  should listen to this event. Previously, all torrent errors were also emitted on
+  `client.on('error')` and handling `torrent.on('error')` was optional. This design is
+  better since now it is possible to distinguish between fatal client errors
+  (`client.on('error')`) when the whole client becomes unusable versus recoverable errors
+  where only a single torrent fails (`torrent.on('error')`) but the client can continue to
+  be used. However, if there is no `torrent.on('error')` event, then the error will be
+  forwarded to `client.on('error')`. This prevents crashing the client when the user
+  only has a listener on the client, but it makes it impossible for them to determine
+  a client error versus a torrent error.
+
 ### Fixed
 
-- When there is a `torrent.on('error')` listener, don't also emit
-  `client.on('error')`.
+- If `client.get` is passed a `Torrent` instance, it now only returns it if it is present
+  in the client.
+
+- Errors creating a torrent with `client.seed` are now emitted on the returned `torrent`
+  object instead of the client (unless there is no event listeners on
+  `torrent.on('error')` as previously discussed). The torrent object is now also destroyed
+  automatically for the user, as was probably expected.
 
 - Do not return existing torrent object when duplicate torrent is added. Fire an
   `'error'` event instead.
 
-- Memory leaks of `Torrent` object caused by various internal subclasses of WebTorrent,
-  including `RarityMap`, `TCPPool`, `WebConn`, `Server`.
+- Memory leaks of `Torrent` object caused by many internal subclasses of WebTorrent,
+  including `RarityMap`, `TCPPool`, `WebConn`, `Server`, `File`.
 
 - `client.ratio` and `torrent.ratio` are now calculated as `uploaded / received` instead
   of `uploaded / downloaded`.