explain the relationship to semantic-release

[bcoe]

@stevemao recommends adding a section to the document describing the relationship between conventional-changelog and semantic-release:

• conventional-changelog: is a loose standard for annotating your pull requests, and generating a version bump and changelog.
• semantic-release: fully automates your release process, using the conventional-changelog format.
• conventional-recommended-workflow: is a replacement for npm version, implementing a workflow recommended by @stevemao.

@boennemann have any thoughts you'd like to add, I see this tool as useful for engineering teams like npm, who want to start adding more structure to our commits but aren't quite ready for a fully automated release process.

[stevemao]

Thanks Benjamin for writing this up.

conventional-changelog: is a loose standard for annotating your pull requests, and generating a version bump and changelog.

I think this is probably true from your perspective. However conventional-changelog only generates changelog, nothing else.
conventional-changelog itself is just an unopinionated wrapper to transform git commit messages to anything (mostly markdown). The build-in presets are probably the standard (rules on how it should transform). npm could use it's own commit message convention if you don't like any of the presets.

The overall workflow is more of a common sense I think. The confusion starts from npm version. npm version modifies package.json, git commit and git tag. But you really want to generate a changelog after modifying package.json and before git tag.

[stevemao]

semantic-release: fully automates your release process, using the conventional-changelog format.

This should probably say "using the conventional-changelog: angular format." or "using the conventional-changelog to generate changelog".

[bcoe]

@stevemao I'm a big fan of "keep it simple and opinionated", like how standard-changelog simply uses the angular format ... as with standard itself, I think promoting this approach will help things get wide adoption.

Perhaps I can edit the documentation to reflect the fact that I'm being a bit opinionated (I think some of your suggestions already help with this).

While I've got your attention, any plans to move the conventional-changelog ecosystem into an org. What I found hardest getting up and running, was pulling together information across several projects -- it would be really slick if there were a single org and eventually website that explained this idea in a concise way.

[stevemao]

Yes and yes.
I already created an org if there are more contributors. I also have some ideas on the website and how conventional-changelog could combine with other technologies.