Finish automating build

[jtpereyda]

Travis currently deploys to PyPI when it gets a tag from Github. However, the release checklist (see CONTRIBUTING.rst) still requires manual interaction:

• bump version number
• commit and push version number
• add tag to Github

Ideally, whenever we merge a PR to master, Travis would do these steps for us and push out a new dev release.

[jtpereyda]

Looks like we can whitelist master to only do things once they get into master:

branches:
  only:
    - "master"

Source: travis-ci/travis-ci#1147

[jtpereyda]

We can use a little script to bump the version number, commit, and push.

Some examples can be found here: travis-ci/travis-ci#1476

[jtpereyda]

General plan:

1. Create Travis step to run only on master, and only when there is not a tag.
2. Use step to bump version number, commit, tag, and push with tags.

Possible issue: If PRs are merged close to each other, the push above could fail. That's probably OK though, since the new PR merge will eventually push with tags and run the deployment. :)

https://gist.github.com/domenic/ec8b0fc8ab45f39403dd#get-encrypted-credentials

[jtpereyda]

The other question is how to handle version number increments. I planned to just increase the dev number each time, and then manually control real releases. This involves a manual step though. But how to increase a version number is a human decision. See this article: http://blog.ploeh.dk/2013/12/10/semantic-versioning-with-continuous-deployment/

Using a dev release really only makes sense if there is a gap between dev releases and real releases. For example, if we had manual tests that we ran for real releases, or dev release users who acted as beta testers.

The problem is that a dev release must specify which actual release it is for.

Plan:

1. Automatic dev releases (increment the fix version, then append the dev version) for continuous deployment.
2. Maintainer-controlled real releases.

This gets confusing when the version number jumps a major or minor version. Then you'll have a situation where, say, 1.3.4dev5 ends up not being included in 1.3.4. Instead, 1.3.4 gets set to dev4, and the dev5 version goes into 1.4. This is actually OK, except that if the maintainer loses track of these, he will have to untangle what gets released where.

... Maybe it's good enough for now.