Add changelogs for releases please

[leeyeh]

will save me a lot of time as I don't need to go through all commits.

Thank you.

[dcodeIO]

This is a valid point, of course. I am not doing this because I'm spending my time on improving the library in the first place. Would you like to contribute some?

[leeyeh]

Good to know.

I love this project but I don't have much time for it. I will recommend https://github.com/conventional-changelog/conventional-changelog-cli to make changelogging easier.

[dcodeIO]

Going to take a look at conventional changelog. Might be supporting it for versions > 6.3.0.

[paralin]

@dcodeIO I'm quite familiar with the angular changelog + semantic release type stuff, would you like me to set it up + make a PR?

There's two approaches to this.

In both approaches, you use a strong commit format:

• chore(scope): did something
• feat(scope): added x

There's a number of different types of commits, detailed in the Angular style guide. There's also a tool called git cz which you can install with npm install -g commitizen which lets you type git cz to interactively write your commit message.

The scope is optional but will show up in the changelog - it's like a category. The commit message is all lower case and shows up in changelog if it's a feat, fix, or refactor.

The two approaches are:

• Keep a separate "release" branch. When you are ready to release, PR from master -> release. Once the tests pass, merge the PR. Tests will execute on the release branch triggering an automatic release to NPM. The automatic release will analyze your commits and determine if a 1.x.0 or 1.0.x bump is required, make the bump, publish to NPM, make a Git tag, push the Git tag to GitHub, make a GitHub release with the changelog.
• Do the same release process as now but run npm run github-release to make a github release with the changelog after you push the release tag.

Which would you prefer? I use both options in my projects. I really like semantic release but if you want strong control over the version # then use option 2.

[dcodeIO]

What I currently have is: Generator - CHANGELOG

I usually tend to break things into what I actually need, which is a changelog, not another project's release process. While the above isn't fully automated yet, it is capable of generating changelogs including (limited) backwards compatibility for old commits based on my usual phrasing.

[dcodeIO]

I also generated the old changelogs now and the changelog script should, potentially, be ready for use.

[dcodeIO]

Closing this for now as changelogs are now in. Feel free to reopen the issue if there are any issues!