Document release process

[macklinu]

@orta thanks for giving me NPM publish access (#116 (comment)). I wanted to open an issue to add documentation to the README about publishing this package.

My assumptions on how this would go:

• Bump the version number. In the case of Don't output table if no violations are specified #116, I would run npm version patch to create an 0.10.1 bugfix version (which would also create a git tag). We could coordinate on minor and especially major version releases, but I would feel comfortable shipping 0.10.1 as a bugfix release.
• Push that commit to GitHub
• Run npm publish, which would build and publish danger to NPM

Could you please clarify? I'll turn this issue into a PR with documentation. Thanks! 😄 🚢

EDIT: should have checked before opening the issue, but 0.10.1 was shipped in 8775f48, which looks like we just:

• Bump the version number manually
• Modify the changelog to include the new version number
• Commit that and push to GitHub
• Run npm publish?

[orta]

Yep, it's all of that on the bottom 👍

[orta]

In Ruby I tend to do a PR with the changes then self-merge, I'll start doing that here too:
danger/danger#705
danger/danger#690
danger/danger#676

[tivac]

Any reason not to have Travis do the publishing of tagged commits to NPM? It's super-easy!

I've started setting up my repos so that running npm version will kick off tests, update the changelog, push the commit, and then travis publishes. I love it.

[orta]

I'm into this, yeah :D

For me npm version just shows some metadata?

[tivac]

npm version <new-version> where new-version is one of major/minor/patch to auto-increment that field, or some arbitrary version like 1.2.3-rc6 to set it to that specific value.

It'll run any preversion/version/postversion hooks in package.json scripts, change the version field in package.json to match & if run in a git repo will submit a tagged commit w/ the package.json change.

docs

[macklinu]

This sounds like a great idea, @tivac. 👍

So we should be able to use something like this in .travis.yml:

deploy:
  ...
  on:
    tags: true

And when npm version creates a new tag and we push to GitHub, it will deploy that new version to NPM, right?

I'm wondering how we will update the changelog, and I poked into a repo of yours to see if I could find an example, @tivac. Looks like we could use the @studio/changes package and perhaps similar pre/post/version scripts as seen in your mithrill-codemods repo as a starting point (let me know if you have other suggestions too).

[orta]

I'm wary of automating the creation of CHANGELOG entries

I consider the CHANGELOG to basically be the main way people see update information, so it should be written with users in mind, whereas commits and PRs tend to use "I work on danger" specific terminology. Which is why it can be one of the only places I'll be pedantic on a PR.

Happy to have it basically take new version from package.json or wherever and prepend it below // Add your own contribution below though? This is what I do basically anyway

[tivac]

@macklinu yeah, since npm version creates a tagged commit when you push to GH Travis will see it, trigger two builds (one for the branch, one for the tag) and the build for the tagged commit will use encrypted npm auth token to push the package to npm.

@orta that's totally fair. I use @studio/changes because otherwise I have terrible habits and don't do a changelog at all. I use validate-commit-msg as a precommit hook (via husky) to ensure that my commits are formatted nicely and then usually just tidy those up for the changelog entries.

Not saying you have to use those patterns, but I find them helpful to curtail some of my bad habits!

[macklinu]

Happy to have it basically take new version from package.json or wherever and prepend it below // Add your own contribution below though? This is what I do basically anyway

This sounds good, and I think @studio/changes will help us enforce this if we want to do it manually:

Or we can find a way to automate that behavior too. 👍

[tivac]

I don't do much tweaking of the generated CHANGES.md file, but you could certainly use the commit messages it auto-populates as a jumping-off point to write more detailed changelog entries! It'd just be like a nice little inline reminder of what was actually in the release at that point 😄

[orta]

I've set up travis so that tags can deploy 👍 will see what npm version patch looks like`

[orta]

interesting, not seeing it working

[orta]

OK, https://travis-ci.org/danger/danger-js/jobs/196765527#L479

[orta]

I'm tempted to move entirely to semantic-release but I do like the ability to ship a few PRs together, allowing for larger bits of work

[orta]

I decided against semantic-release - the whole reason that the Moya contributors policy works is because we can take the time to fix before release, instead of shipping every PR. Happy to call this done.