Now we have some sanity checks, a way to skip them and a way to see which
commands would be executed on the git and npm side without actually
executing them.
It is customary to use annotated tags for releases, to preserve the
information about when the tag itself was created, by whom and for what
purpose. In our case we always have a commit directly before the tag, but
some workflows may expect annotated tags nonetheless, “git describe” among
them. We might want to sign them one day, too.
Summary: The previous commit made the `sed` lines do the same thing on mac and
linux. Unfortunately they didn't actually work. Whoops.
Test Plan:
- Run `./release.sh` a couple times and become horribly confused before
realizing what's going on.
@kevinb
Summary:
We prevent any precommit checks so that we don't have to include
a "Test Plan" etc. in the release commit message.
Test Plan:
- ./release.sh 0.6.0 0.7.0
Auditors: emily
Summary: Make the release script that's been floating around in my gists
for a while into a real script.
Test Plan:
- Comment out all the scary bits (the two pushes, and `npm
publish`), and run:
- `./release.sh 0.6.0`
- Checkout the `v0.6.0` tag, see that it successfully modified
package.json and bower.json to version 0.6.0, and built and committed
the rest of the files.
- `git tag -d v0.6.0`
- `./release.sh 0.6.0 0.7.0`
- Checkout master, see that it successfully made a commit bumping
package.json and bower.json to 0.7.0-pre.
Reviewers: @kevinbarabash
