New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add changelogs for releases please #574

Closed
leeyeh opened this Issue Dec 19, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@leeyeh

leeyeh commented Dec 19, 2016

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

Thank you.

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Dec 19, 2016

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?

@dcodeIO dcodeIO added the enhancement label Dec 19, 2016

@leeyeh

This comment has been minimized.

leeyeh commented Dec 19, 2016

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

This comment has been minimized.

Owner

dcodeIO commented Dec 19, 2016

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

@paralin

This comment has been minimized.

paralin commented Dec 19, 2016

@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 added a commit that referenced this issue Dec 20, 2016

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Dec 20, 2016

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 added a commit that referenced this issue Dec 20, 2016

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Dec 20, 2016

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

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Dec 27, 2016

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

@dcodeIO dcodeIO closed this Dec 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment