should we ditch the changelog tooling?

[tomwayson]

I spent over 2hrs trying to cut a release today.

• no one is using npm run c
• @dbouwman says it can fail sometimes, possibly due to the issue where [Unreleased] ends up underneath the latest release?
• this sucks
• it becomes the job of whomever is cutting the release to manually come up w/ CHANGELOG entries that look like the generated ones

I'm over it.

[drewdaemon]

Fair. npm run c was only failing for me because of the Husky version. Since I bumped it, the problem was solved ¯_(ツ)_/¯

[tomwayson]

This looks like a good alternative: https://about.gitlab.com/blog/2018/07/03/solving-gitlabs-changelog-conflict-crisis/

[haoliangyu]

https://commitlint.js.org is cool if you want to enforce the commit message format used by npm run c. But that's another tool in the chain ¯\(ツ)/¯

[r00b]

also over it

[gavinr]

Idea/Goal: can we switch to automatic releases through semantic release? We would need to make sure it works with monorepos.

[drewdaemon]

@gavinr totally IMO. I know that @dbouwman had that in the works for Hub.js (another monorepo). I'm not sure where that's at or what kind of a task it would be to make it happen here.

[patrickarlt]

@gavinr @tomwayson if someone elses wants to lead the charge with semantic-release or standard-version I would be all for it for 4.0. I'm undecided on how to handle this in #911