discuss preparing an npm module for release from git

[bewest]

The tool uses git-extras to automatically prepare a repo for "release"-like status. It increments the version number in package.json using the same semantics as npm version, in addition to preparing some release notes specific to this release.

It was designed with the following priorities:

• I wanted a tool which would allow me to create a pull request on a branch to allow previewing and discussing the release.
• After previewing and discussing, it gets merged into master, and I manually push the tag back to github using git push --tags origin.

I often use this to preview the commits and the results of the process, and I like having most of the manual labor automated. The git-release tool in git-extras automatically performs network operations, which I disagree with. I want the opportunity to preview what has happened before sending it over the network.

Using this tool has allowed me to expose and fix errors performed by myself and others.

The tool also makes it easy to communicate what is in an individual release, in terms of one-line commit summaries very easy. If the commit one-lines are written well, this can be a good way to prepare more of a narrative of the release, with hints on what to test. Once everyone is happy with the release, it's easy to merge, and perform the network activity to officially publish it with confidence.

Consequently the automation here is intended to address those two aspects of preparing releases:

• previewing, obtaining visibility, and achieving consensus on releases of "official code" published by tidepool
• finding and fixing problems caused by manually tagging/versioning things

How to deal with release notes, formatting, etc, isn't really the primary objective here, just being able to reliably produce an upgraded npm module.

A few caveats, the name

• ./prep_repo_release.sh leaves something to be desired
• What happens to release notes is very much up for discussion I did the minimum thing to provide some record of version specific releases. If we have a policy for release notes, the tool can be ammended to do that. I found git-changelog to be a helpful starting place. This seems like a reasonable starting place for discussing how we might want to save some manual effort on release notes.
• It looks more dangerous than it is. npm version modifies your git repo, for better or worse. The reset undos the damage done to the repo by npm, and ensures that the commits are automatically generated do not happen on the master branch. It also provides a better pivot point for defining the tagging mechanism actually works, eg this is a reasonable starting point for adding a segment that PGP signs the tag using tidepool.org address, perhaps using the release notes for the tag annotation, etc...

[bewest]

usage notes

$ ./prep_repo_release.sh [major|minor|patch]
Prepare and review an impending npm release for your git repo.
  * version specific release notes via git-changelog -t
  * bump package version via npm version
  * Create semver tag pointed at result.
  * leave all commits on branch named `release/$TAG` for PR/review