Development

Versioning:

Development follows a Gitflow workflow. At the highest level, these are the guidelines:

The HEAD of the master branch is always the last release of the latest major version.
New release changes are only merged (without squashing) from a develop branch.
Bug fixes and feature development are done in branches off of the develop branch, which are squashed when they are merged back into develop.
All release tags are on master or release branches from master.
If bug fixes or feature back ports are needed for an older major version release, a release branch will be created at the release tag, e.g. HEAD of master is at version 2.0.0, a fix for version 1.2.0 will be done in a 1.x release branch from master. New minor releases to that branch are tagged on that branch.

Changes are created in a branch from develop (for committers) or a pull request (for external contributors) against develop, or an older major release branch.
Changes are reviewed by a committer, with explicit approval noted in the PR comments.
The PR is merged by any committer to develop, with all commits squashed and a concise message.

Once a release stage is determined ready within the develop branch:

Make sure the version and ChangeLog are updated appropriately and committed to develop
Merge all commits from develop onto master (without squashing)
Tag the release on master and add release notes to Releases entry.

Push update to PyPI:

python setup.py sdist
twine upload dist/*

Pushing to test PyPI can be done via:

twine upload --repository-url https://test.pypi.org/legacy/ dist/*
...
pip install --index-url https://test.pypi.org/simple/ mseedindex