... | ... | @@ -11,6 +11,7 @@ New features should be discussed with the core development team before they are |
|
|
### Development
|
|
|
|
|
|
* New features or bugfixes (initiated by a ticket in the issue tracker) are developed on a separate branch (e.g. `feature_xy` or `bugfix_xy`) or on the general development branch (`development` or `<new-version>-development`) depending on the size of the change.
|
|
|
* Commits on the development branch have to be reviewed by a member of the core development team. If feature branches are merged into the development branch before their final merge request into `master` they have to be reviewed as well.
|
|
|
* When the desired changes are implemented, tested, style-compatible and working the performed changes are described in the file CHANGELOG which every sub-project contains in the root folder. Also the README and further documentation of the tool is adjusted to the changes.
|
|
|
* A merge request to branch `master` is submitted
|
|
|
* **Another** developer of the core-team checks,
|
... | ... | @@ -21,7 +22,7 @@ New features should be discussed with the core development team before they are |
|
|
* [ ] *Good Code*: The code shows a good quality
|
|
|
* If one of the upper points is not fulfilled the one who requested the merge is informed which issues still have to be fixed
|
|
|
* Otherwise the developer who reviewed the merge request merges the new branch into the `master` branch
|
|
|
* During the merge new version number is assigned (see section versioning). Several merge requests can be combined under a single new version number.
|
|
|
* During the merge new version number is assigned (see section versioning). Several merge requests can be combined under a single new version number. Therefore merge requests may be withheld.
|
|
|
* The commit is then marked with a tag representing the version number. This tag may not be moved anymore.
|
|
|
* The new version of the binary is published on the website.
|
|
|
|
... | ... | |