Update CHANGELOG for 2.0.0 release

[pboling]

Would like to release 2.0.0 tonight.

[coveralls]

Coverage remained the same at 97.321% when pulling a05111d on changelog into 501f56d on master.

[andrykonchin]

I am not sure semantic versioning works well now.

I plan several breaking changes (2-3) and not sure they will be released all together in the same release. So SemVer requires to increase major version every time and it will look strange to get 4.0 version in a half a year

[coveralls]

Coverage remained the same at 97.321% when pulling c5a6793 on changelog into 501f56d on master.

[pboling]

@andrykonchin
It is important to communicate the risks of upgrading to the users though, and semantic versioning is the standard way of doing that. We can either think hard about maintaining a deprecated "API" serviceable that works with the old way when we make otherwise breaking changes, or we can bump the version.

The rake gem often bumps the major version, and some other gems do as well. If the gem is undergoing upheaval it is important to communicate. There isn't too much value in keeping the same version number. We want people to conscientously upgrade, and with a major version bump they are more likely to check the changelog. It will also make the versioning work automatically with dependency management services like depfu.

Concerns about the image of jumping quickly to a version 5.0 in a short period of time take a back seat to not breaking people's apps unexpectedly.

Having said that, we've already bundled 3 breaking changes into current HEAD. If you want to get more in we can wait to release. There is definitely some value in not jumping the version number quickly.

What timeline do you anticipate for these new breaking changes?

Let's plan a release date for 2.0!

[andrykonchin]

I suppose the easiest change will be ready in a month so it doesn't make sense to wait for me.
Let's release now.