Add changelog

[tiffon]

Non-functional change.

Adds a CHANGELOG.md document that details merged PRs.

Starts from late August, 2017.

Signed-off-by: Joe Farro joef@uber.com

[coveralls]

Coverage decreased (-0.2%) to 69.951% when pulling 0b45fa8 on add-changelog into 013d2a6 on master.

[coveralls]

Coverage decreased (-0.2%) to 69.916% when pulling f5797b5 on add-changelog into 013d2a6 on master.

[saminzadeh]

If we are going to introduce a Changelog, its better we start versioning the UI and creating a release process. The changelog seems like a git log history now

A better format would be something like this:

## 0.0.1
[New Features]
- Feature 1 (PR num)

[Bugs]
- Feature 1 (PR num)

[Breaking Changes]

etc

[coveralls]

Coverage increased (+0.2%) to 70.299% when pulling 869861d on add-changelog into 013d2a6 on master.

[tiffon]

@saminzadeh If we go with a versioned release process for the UI, then I think we should we keep it independent and departed from any other versioning in the project. Primarily, the all-in-one docker image.

I think the two versions should operate separately because they basically are completely separate. This is illustrated by the fact that the current all-in-one, released on 9/24, is running the UI from 8/8. Trying to force them to be consistent is going to add cognitive overhead and require more coordination.

The sitaution becomes further complicated if we go down the plugin extensibility route. With the exposure of a plugin API, the versioning of the UI will no longer be arbitrary, and keeping the UI version synced with the all-in-one version could be untenable.

What do you think?

Regarding format, based on your feedback and Yuri's, I've pared it down. What do you think?

@yurishkuro Is this format more aligned with what you had in mind?

@saminzadeh FYI, I'd add you as a reviewer (thanks for your feedback) but you don't show up in the list... :/

[coveralls]

Coverage increased (+0.07%) to 70.195% when pulling a86c11e on add-changelog into 013d2a6 on master.

[saminzadeh]

@tiffon

If we go with a versioned release process for the UI, then I think we should we keep it independent and departed from any other versioning in the project. Primarily, the all-in-one docker image.

That's fine, my main point is that a Changelog is only effective if we have some kind of versioning in place. Whether that means jaeger-ui having its own or having it be versioned with jaeger query project (given that its bundled with it).

From wikipedia via http://keepachangelog.com/en/1.0.0/

A changelog has historically included all changes made to a project. The "Keep a CHANGELOG" site instead advocates that a changelog not include all changes, but that it should instead contain "a curated, chronologically ordered list of notable changes for each version of a project" and should not be a "dump" of a git log "because this helps nobody".

Currently, it seems like a list of features that are supported without pointing to a specific date or version so its not really clear if the changes are present or not in the version you may be running.

Furthermore, the Jaeger Query service changelog should incorporate which UI version its using.