Use bumpversion for version number management

[jessetan]

This is an alternative for #812. It uses a CLI tool to bump the version number so we can manage it in a single place.
The benefit over #812 is that it actually writes the version number to the files, which means that we do not rely on pkg_resources.get_distribution (which breaks if the package is not pip-installed) and we do not read it from setup.cfg (which may cause trouble with reathedocs.org code)

I hope that this PR contributes to the speed at which we can release dev builds, so we can get better and earlier feedback.

Release instructions have been updated, but the process is:

1. bump the version using bump2version [major|minor|patch|dev]. Using major|minor|patch will always have a dev0 suffix, using dev will bump the number in the suffix (dev0 -> dev1 -> dev2)
2. If you want to release a dev version, proceed with the other steps
3. If you want to release a release version, run bump2version --allow-dirty release to remove the devX suffix. The --allow-dirty flag is needed to prevent complaints about non-committed changes.

[agjohnson]

Ah, interesting idea. I didn't know about this tool. We have scripts that perform some of the same functions for our other repositories already. It might make sense to standardize on a common tool instead of custom scripts across our repositories.

[agjohnson]

I'd be 👍 on this I think. It seems like a better approach than assigning the version programmatically like we do in other repositories. I'll raise standardization on this workflow separately.

I might have interpreted docs incorrectly, so having some clarification might help the release docs.

[Letme]

How about we use setuptools_scm where we generated a fixed file __version__.py at packaging time, so that you can than just read that when asking for version?

Requires no manual interaction - you just tag and it will automatically release (with some help of .travis-ci.yml)

[jessetan]

Using setuptools_scm could make releases easier. Do you know if it supports releasing dev versions to pypi?

[Letme]

I added a simple pull request to demonstrate the usage. Yes, it supports releasing dev versions to pypi - thats what travis will handle for us.

[agjohnson]

We have more than the python package version number to change, so I lean towards hard coding the version number with the tool here. In readthedocs.org repository, we read this from setup.cfg, but I think this PR is probably a better solution. I'm looking to get away from solutions that need to execute python.

[agjohnson]

Also, I'm considering our other repositories and a more generally adopted pattern. Having a general tool like bump2version will get us more flexibility to fit the pattern in our other repositories

[Letme]

The write_to option takes also write_template as option for non txt or py files. Anyway, just decide and lets go.

[agjohnson]

I made two small changes here:

• Changed the versioning guidelines for development releases to match our other librarys. We don't use the .dev0 postfix, we use alpha1 and rc1 for other packages. I was have trouble getting bump2version to support both. I think alpha1 works in the same way .dev0 would however.
• Moved the config to setup.cfg with the rest of the tool configurations. I see some benefits to both, and we can always move back if we hit issues.

[agjohnson]

There hasn't been any opinions around adopting this across our repositories, but I'd like to at least try testing things here. I'm 👍 on this PR and hopefully we can do something similar with our other repositories.