Rcognita's development guidelines

Branching, commiting, tagging

Do not commit to master
Do not branch from any existing branch other than dev and its sub-branches.
If you are performing a small fix/adjustment, you may commit directly to dev.
If you are introducing a new feature or performing a major adjustment, you should create a new branch from dev. The name of this newly created branch is to be prefixed by feature- or adjustment- accordingly. It is up to you to decide, how those branches are sub-branched. Make sure you send a merge pull request (into dev), once you have implemented and tested your feature/adjustment.
Do not use tags like vx.x.x and so on. Those are reserved for releases.
Prefix your tags with the name of the feature you're currently developing. I.e. a branch called feature-foo should have tags prefixed with foo-. Exceptions can be made when such exceptions are resonable.
The above rules do not apply to rcognita's forked dependencies (i.e. AIDynamicAction/mpldatacursor, AIDynamicAction/SIPPY). Each of those repositories have a branch called rcognita-dependency. Just commit directly to that branch.

Titles of issues that regard your feature-/adjustment- branches, should be prefixed with the branch's name. I.e. "feature-foo Crash upon launch". Mind the backticks.
It is strongly encouraged to report your current obstacles and TODOs in "Issues" even if you're the only one working on the branch. Don't forget to assign yourself. Don't hezitate to utlilize "Issues" as your personal development-notebook even if you end up creating many small issues.
Issues that regard rcognita's forked dependencies should only be reported in rcognita's main repository.

It is mandatory to produce informative docstrings for your code using reStructuredText markup. It is advised to write a doscstring for each module, class, function and method. Exceptions can be made for auxiliary definitions that are unlikely to be dealt with by anyone other than yourself. Be sure to make use of info field lists.
The docs are built by running:
```
   cd docsrc
   make
```
The docs will not build unless all of rcognita's dependencies are satisfied. The build log will contain around 20 warnings upon successful compilation.
Once a feature-/adjustment- is merged into dev, the docs should be built.
Building docs before your feature-/adjustemnt- branch is merged into dev is discouraged, since it may complicate the upcoming merge.
Do not directly edit anything within docs and docsrc directories, unless you know exactly what you're doing. Modules can be described by editing a """ X """ comment at the top of the module.
README.rst is integrated into docs, so keep in mind that if changes were made, you'll need to rebuild the docs (at appropriate time).
Do not confuse class attributes with constructor (__init__) arguments, when writing docstrings.

When performing a release:
- git checkout dev
- Set rcognita.__init__.__version__ accordingly
- Build docs
- Merge dev into master.
- Create appropriate version tag (vx.x.x)
- Run:
```
    rm -rf dist 
    python setup.py sdist bdist_wheel
    twine check dist/* 
```
  If all files pass the check, proceed with
```
   twine upload dist/*
```
- Ensure rcognita and all of its dependencies can be correctly installed via
```
   pip-autoremove rcognita[SIPPY] -y
   pip install rcognita[SIPPY]==x.x.x
```
- If no issues occur, publish the release at github with the version tag you created earlier. The description should include "Available on PyPI via pip3 install rcognita==x.x.x". Make sure you delete this release (but not the tag) if any fatal flaws are discovered later.
The above instructions can be used to deploy rcognita's forked dependencies.
You cannot amend a release on pip, besides it is unnescessary. If a release is discovered to have had a fatal flaw, just create a new one. Just make sure the old one is deleted from github releases, as mentioned earlier.
If you're accepting a merge pull request, DO NOT delete the branch. ESPECIALLY IF YOU'RE MERGING dev INTO master.

New dependencies should be added to the appropriate list in setup.py.
Not all dependencies will necessarily be backward compatible in the future, hence, when adding a dependency, a single version should be specified with ==.
If a potential dependency "foo" is not listed on PyPI or if it requires some modifications, the following steps should be performed:
- Fork foo's repository as AIDynamicAction
- Checkout the commit that corresponds to the version that you're interested in. I.e. via a version tag git checkout vx.x.x
- Branch rcognita-dependency from that commit and checkout that branch. If you're doing it locally, don't forget to push the branch to origin.
- In setup.py change the name parameter from "foo" to "foo-rcognita"
- Commit necessary changes.
- Upload to PyPI (see Merging and releasing #1)
- Add "foo-rcognita == x.x.x" to the list of rcognita's dependencies as described in #1
- Information about required external dependencies (the ones you install with sudo apt-get install xxx) should be added to README.rst's "Installation" section.
If you decide to introduce further updates to the forked dependency, don't forget to change the version in the forked repo's setup.py before trying to upload to PyPI. Naturally, you should also edit rcognita's requirements accordingly in the main repo's setup.py.