From 713c86883853fb1dd654b1c64b15f0e267ada940 Mon Sep 17 00:00:00 2001
From: Floris Bernard <floris@mediamonks.com>
Date: Mon, 25 Feb 2019 10:13:36 +0100
Subject: [PATCH] Add 2.0.0 changes to CHANGELOG

---
 CHANGELOG.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index d0ff7e6..c7e1b2c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,67 @@
+# V2.0.0
+
+## New features
+Most new features are centered around better typings
+
+### EventDispatcher can be restricted to certain event classes
+You can now pass a generic parameter to `EventDispatcher` indicating
+which type of events it will dispatch. Besides it being documentation to
+other developers about which events to expect, it also allows this library
+to add more useful typings to methods like `addEventListener`. Example:
+
+```ts
+class Scheduler extends EventDispatcher<SchedulerEvent> {
+```
+
+### It is now easier to create event classes
+Event classes can still be created by manually extending `AbstractEvent`.
+However, this is somewhat verbose. Moreover, it is very common to want to
+have some kind of `data` property on an event. This is now possible using
+2 new utilities: `createEventClass` and `createIsomorphicEventClass`. See
+the [readme](README.md) for more info.
+
+### Event classes can have isomorphic data or options
+Previously an event class was either fixed to a set of options and a certain
+type of `data`, or it was type too loosely. It is now possible to have the
+options and the `data` depend on the event `type`. 
+
+## Removals
+
+### Removed `CommonEvent` and `BasicEvent`
+As it is now very easy to create your own strongly typed event classes,
+it no longer makes sense to export generic classes. Instead, we
+should encourage the definition of classes tailored to your project.
+
+### Removed `IEventDispatcher` and `IEvent`
+These interfaces contain a lot of duplication with their corresponding 
+classes, and were slowing down development. Typing things like so will 
+also remove the strong typing. The rationale behind it was that we 
+theoretically could have `EventDispatcher` interact with a custom
+implementation with the same interface, but this is rarely to never done.
+When wanting some kind of custom functionality, it usually suffices to 
+extend `EventDispatcher` and override the methods. 
+
+It's also worth mentioning that there was no advantage to `IEvent` at all,
+as `AbstractEvent` only has public members. This makes it possible to 
+create a class that `implements AbstractEvent`.
+
+### Removed `eventTypeUtils` (like `generateEventTypes`)
+Our new `createEventClass` utility has a better syntax
+
+## Testing
+Tests are now implemented using Jest. Additional test have been added using 
+`dtslint`, allowing us to do assertions on the types in the TypeScript compiler.
+
+## Other small fixes 
+
+- A lot of `private` fields have been changed to `protected` to allow for
+more extensibility
+
+## Compatibility
+Requires at least TypeScript 3.1, for the [mapped tuple type](https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#mapped-types-on-tuples-and-arrays)
+functionality.
+
+
  * private => protected
  * remove interfaces
- * typings
\ No newline at end of file
+ * typings