Workflow

We use a workflow similar to that of the Annex 60 Library. Therefore, the following text is taken from the Annex 60 Wiki with minor modifications:

We have two major, permanently existing branches:

1. master - This branch should always be a stable version. Bugfixes will be merged directly into the master, with changing version number (eg. from 0.1.12 -> 0.1.13, see Semantic Versioning) and a new release on GitHub.
2. development - Between each each minor (e.g. v0.1.13 -> v0.2.0) and major (e.g. v1.6.5 -> v2.0.0) release the development of new features and minor revision is coordinated in this branch. The targets of each release are documented via Milestones (e.g. Milestone v0.3.0). After all issues of a release Milestone are successfully implemented in the development branch, the development branch is merged into the master, and a new version will be released. The development branch is also kept up to date with the master (bugfixes).

If you want to contribute to AixLib, please follow this workflow:

1. Open a new issue, and assign it to the one who can address it (which may be you).
2. Make a new branch starting from the development branch (new features) or from the master branch (bugfixes). Call this branch something like issue17_templateBoiler, use the issue number and a brief description of the revised feature/bug.
3. Document your changes on the issue tracker and implement them on the branch. 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. When done with the implementation:

• merge the latest version from the development for features or master for bugs to your branch
• make a pull request from your branch to the development/master
• assign the issue to someone for review and for merging it into the development/master branch

5. When reviewing other's code, add your comments on the issue tracker
6. If the revisions are reviewed and correct, merge the pull requests to the development/master, delete the branch and close the ticket. If the revisions need further work, assign the issue to the original author.

Note that only the person who reviewed the code will merge it to the development/master. Don't merge your own revisions without having them reviewed.