Add changelog generation and commit message convention

[dignifiedquire]

Examples of projects using strict commit message conventions to auto generate changelogs

• https://github.com/angular/angular.js
• https://github.com/karma-runner/karma
• https://github.com/codemirror/CodeMirror
• https://github.com/emberjs/ember.js

Possible commit message conventions

• angular
• atom
• codemirror
• ember
• eslint
• express
• jquery
• jshint

Eco system in npm land

• https://github.com/conventional-changelog/conventional-changelog-core
• https://github.com/conventional-changelog/conventional-github-releaser
• https://github.com/btford/grunt-conventional-changelog
• https://github.com/conventional-changelog/gulp-conventional-changelog
• https://github.com/conventional-changelog/atom-conventional-changelog
• https://github.com/conventional-changelog/conventional-changelog-cli
• https://github.com/commitizen/cz-cli
• https://github.com/ajoslin/angular-precommit
• https://github.com/marionebl/conventional-changelog-lint
• https://github.com/conventional-changelog/standard-version

[daviddias]

ref: ipfs/community#145

[victorb]

Semantic Release (wonderful utility for automatic package publishing) is using the Angular convention, worth looking into: https://github.com/semantic-release/semantic-release#default-commit-message-format

[dignifiedquire]

@victorbjelkholm also look at the last link in the original issue, standard-version does something similar as far as I understand

[dignifiedquire]

Nvm semantic-release is much more comprehensive, need to look at that, could be super nice for us

[victorb]

@dignifiedquire ah, that's true. standard-version mentions semantic-release over here: https://github.com/conventional-changelog/standard-version#how-is-standard-version-different-from-semantic-release

Seems like standard-version does a subset of what semantic-release does (like pushing and publishing)

[dignifiedquire]

This is a rough draft of things I suggest to adapt, for making the release process as automated as possible while generating high quality releases.

• Use the angular commit convention
  • enforced through a commit hook and a travis check (maybe gitcop or sth similar)
  • squash all commits into sensible units (this means 1 commit per PR in most cases)
  • strongly encourage the use of https://github.com/commitizen/cz-cli to make wrong commit messages less probable
• Bump all modules to 1.0.0 to allow proper semver, with these rules
  • Bug fixes -> patch release
  • Features -> minor release
  • Breaking changes -> major release
• Use the new aegir-release as described below

Steps for new aegir-release

• Run lint
• Run tests
• Run build
• Using conventional-changelog to generate a changelog
  • Manual review and changes to the changelog
• git commit package.json CHANGELOG.md
• Use recommended-bump to suggest the new version
• git tag <version>
• git push
• Push changelog to github releases

Misc notes

• Investigate using something like http://npmjs.org/listr to give a nice progress output
• Make this task standalone so it can be used by others that do not use the rest of the aegirpipleline

[dignifiedquire]

Todos:

• aegir-changelog for previewing the changelog
• pull down the angular commit convention to ipfs-community for feedback (Draft of js git commit convention community#148)
• Add signing of commits for licensing reasons
• Recommend signing commits with gpg keys

[dignifiedquire]

First version is released in 7.0.0

[daviddias]

What do we need to do to finish this one? Let's review it during the next sprint call (//cc @RichardLitt @flyingzumwalt)

[daviddias]

This is done, right?

[dignifiedquire]

@diasdavid still don't have commit validation on CI

[dignifiedquire]

I don't think commit validation on CI is particularly great, we can use the squash option to easily fix commits on merge