Finish automating build about boofuzz HOT 4 OPEN

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

branches:
  only:
    - "master"

Source: travis-ci/travis-ci#1147

from boofuzz.

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

from boofuzz.

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

from boofuzz.

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.

from boofuzz.