Workflow

Structure of TEASER Repository

Branches

The TEASER repository has two major, permanently existing branches:

1. master - This branch should always be a stable version and in accordance to the latest release. There are only two reasons to send a pull request to the master

2. You want to fix a bug

3. You want to publish a new release

4. development - This branch is intended as the base branch for development of new or improvment of existing features.

Versions and Releases

In a given period of time new versions and releases of the TEASER will be published. Every time the master changes, a new version number must be generated see Semantic Versioning.

1. New releases cause a changing version number in the first or seccond digit (e.g. from 0.1.13 -> 0.2.0)
2. Bugfixes cause a changing version number in the third digit (eg. from 0.1.12 -> 0.1.13)

In the milestone section the targets of each relase are documented.

Bugfixes

1. Open a new issue in the Issues section, assign it to the one who can address it (which may be you) and apply the bug lable. The issue has to have a clear title (e.g. Bug in Class Y).
2. Create a new branch starting from the master, call this branch according to the created issue 'issue##_BugClassY'
3. Document your changes in rather small steps/commits. Try to use choose short commit messages (maximum 140 characters). You may want to include in the commit message a string such as #17. This will automatically add a link to the commit from the issue.
4. Watch the evolution of the master if it changes, merge the latest version into your branch.
5. Increase the version number in README.md, setup.py, doc/index.rst and doc/conf.py in a single commit.
6. Create a pull request with master as base and your branch as compare. And assign the pull request to someone for reviewing and merging it into the master.
7. When reviewing other's code, add your comments on the issue tracker. If the revisions need further work, assign these to the original author.
8. If the revisions are reviewed and correct, accept the pull requests, delete the branch, close the issue and publish a new release with a self explaining release title like "Bugfix in Class Y").
9. Upload the new master release to PyPI (Python Package Index). Therefore use the commands:

python setup.py register 
python setup.py sdist upload

you need write acces to the PyPI teaser account (please register at https://pypi.python.org/pypi and ask for it if you need it). and you need to create a .pyirc file in you top level TEASER directory that looks like this:

[distutils]
index-servers =
    pypi
    pypi-test

[pypi]
repository=https://pypi.python.org/pypi
username= USERNAME
password= PASSWORD

[pypi-test]
repository=https://testpypi.python.org/pypi
username= USERNAME
password= PASSWORD

New/improve feature

1. Open a new issue in the Issues section, assign it to the one who can address it (which may be you). The issue has to have a clear title (e.g. New Feature in Class X).
2. Create a new branch starting from the development, call this branch according to the created issue 'issue##_FeatureClassY'
3. Document your changes in rather small steps/commits. Try to use choose short commit messages (maximum 140 characters). You may want to include in the commit message a string such as #17. This will automatically add a link to the commit from the issue.
4. Watch the evolution of the development if it changes, merge the latest version into your branch.
5. Create a pull request with development as base and your branch as compare. And assign the pull request to someone for reviewing and merging it into the development.
6. When reviewing other's code, add your comments on the issue tracker. If the revisions need further work, assign these to the original author.
7. If the revisions are reviewed and correct, accept the pull requests, delete the branch, close the issue

New release

Whenever you accept a pull request into the master, you need to make sure to publish a new release. In the Releases section hit the Draft a new release button, enter the correct new version number and chose a self explaining release title (e.g. v0.2.0 or "Bugfix in Class Y").