Add initial CHANGELOG

[kradalby]

This PR adds a changelog for the 0.12.0, and the way forward.

0.12.0 is a bit thin atm, I think we will do better there in the future.

[kradalby]

This is initial work for #240

[dragetd]

So far it looks like the releases had an autogenerated list of commits - how was this created? Will this be part of the releases, too?

The release-text is used on projects like renovate bot, it is very nice to see the most important and breaking changes in the Changelog.

Also, it would be nice if the the version numbers had an (ISO) date. E.g. (2021-11-29).

I usually open a new development-cycle by creating a top-level changelog entry with (TBD), which is then replaced by the actual versionnumber/date on release:

**TBD (TBD)**

**Changes**:

- Foo


**0.12.0 (2021-11-29)**

**BREAKING**:

- Foo
- Bar

**Changes**:

- Foo
- Bar

But this is a personal taste. Also interesting 'Semantic-releases' (https://github.com/semantic-release/semantic-release), but this requires some discipline when writing commit messages. But maybe interesting to you. :)

Also, how much work would it be to also include a rough changelog for version 0.11.0? :)

[kradalby]

So far it looks like the releases had an autogenerated list of commits - how was this created? Will this be part of the releases, too?

I believe this is an automatic feature from Github releases, or goreleaser? @juanfont

The release-text is used on projects like renovate bot, it is very nice to see the most important and breaking changes in the Changelog.

I suppose the relevant content can be copied from the Changelog, the section for that version.

I usually open a new development-cycle by creating a top-level changelog entry with (TBD), which is then replaced by the actual versionnumber/date on release

Im happy with this format, ill update it.

But this is a personal taste. Also interesting 'Semantic-releases' (https://github.com/semantic-release/semantic-release), but this requires some discipline when writing commit messages. But maybe interesting to you. :)

I can see the idea, but I disagree with this pattern, I don't like the semantics of the FIX:, etc in commits and I dont believe that every commit would carry value for a changelog.

Also, how much work would it be to also include a rough changelog for version 0.11.0? :)

Not sure what change really, I'll have a look, 0.12.0 has been in the works for a while

[juanfont]

So far it looks like the releases had an autogenerated list of commits - how was this created? Will this be part of the releases, too?

I believe this is an automatic feature from Github releases, or goreleaser? @juanfont

Indeed, comes from Github. I reckon it's a pretty terrible format, as we do not squash the commits - so we end up having an enormous list of commits.

I think this is a pretty good format to start with. Let's see how it goes in the next releases!

[kradalby]

Maybe we should edit the version and add the date when we do the release and merge this at that point.

So change it to 0.12.0-beta and publish?

And add a new empty tbd on top so people can add their changes in their pr