Benjamin E. Coe

@kellyselden friendly nudge, mind rebasing if this is still something you want to land?

I've added some tests around environment-based configuration. Note, I've been using my fork of StatsD in production, so the feature has also been tested in the wild.

@stevemao @blackxored; following up from @stevemao's comment. I helped add similar functionality to lerna, to the functionality in standard-version. I think we'd be smart to reference lerna in our README...

@weaintplastic @Conaclos I'll lead with my periodic apology related to disappearing from open-source😛 One thought, perhaps we could document some advanced topics, e.g., using `conventional-changelog` to regenerate commits, in [docs/advanced.md](https://github.com/conventional-changelog/standard-version/issues/226)?

see motivation for a more flexible preset: https://github.com/conventional-changelog/conventional-changelog/pull/421

@stevemao this seems clever 😄 (in the good sense of the word). I might still be inclined to make it a config option that gets turned on.

@crutchcorn I've been slammed with various other projects recently, but would appreciate the patch 👍 [this chat](http://devtoolscommunity.herokuapp.com/) can potentially be a good place to coordinate.

@TimothyJones @cnschwarz `commit-and-tag-version` does look very promising.

Conventional Commits purposely leaves the specification open to folks adding new types: > types other than fix: and feat: are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))...

👋 my two cents,`revert: ` currently fits within the scope of the existing specification, and it seems fair to put the responsibility for how this is interpreted in the hands...