Release 0.2.0

[discordianfish]

Due to the major change to support arbitrary grouping, this deserves a
MINOR version increment.

[brian-brazil]

👍

[beorn7]

There is actually a breaking change in the DELETE API call.

The version increment is fine, but the breaking change needs to be documented.

[beorn7]

I have changed the changelog, and will set the tag to after that change.

[beorn7]

@discordianfish I have updated the release tag and info. Could you use your magic script to attach binaries? (Apparently, it doesn't work on Linux...)

[discordianfish]

@beorn7 The magic script isn't working due to #43 :-/
And sorry for not realizing this is a breaking change. Agreed that it should be included in the changelog. Maybe come up with some general guidelines how to manage those things. I think it would make sense for example to update the changelog in the PRs introducing the change. That way it wouldn't be possible to forget mentioning that in a release.

[juliusv]

In my experience it's much more reliable to collect changelog entries once when you cut the release than to try and think of updating the changelog with every PR (and also remember to make all external contributors do that). Further, the changelog often doesn't end up with per-PR updates, but a lot of stuff is summarized/squashed together in the end.

[discordianfish]

@juliusv Hrm.. but I think at least for breaking change it would be a good idea.

[grobie]

My experience is the opposite of @juliusv.

[beorn7]

Ideally, the person who knows the repository in question best should be involved when cutting the release and/or creating the changelog.

[discordianfish]

Whatever we decide, we should document it somewhere. I prefer adding things to the changelog with the PR, it's also useful for people building from master to have a up-to-date changelog. But I leave this to you.