-
Notifications
You must be signed in to change notification settings - Fork 32
BallDevelopmentModel
BALL in its very nature is a research project. Developers usually are undergraduates or PhD students. Both groups are usually only interested in parts of BALL which are directly linked to their research work. This has various implications for its development model:
1.The willingness to propagate bug reports/fixes, new features, and other enhancements is generally low. This usually results in big merges of > 100 commits at the end of an individual thesis. Of these commits many have already been obsoleted by changes in the main branch or are nearly impossible to merge. 1.The developers proficiency with development tools, such as the Git SCM, and their experience with software development processes is low. 1.The average developer only spends a limited amount of time in the project: the average duration of a thesis. 1.New features have to be rapidly pushed out to the public as fast as possible in order to provide a state of the art solution to users and allow citations in publications.
Obviously these special circumstances are not always beneficial to code quality. The following development process tries to find a balance between ease of use and long term maintainability.
The developement takes place in two repositories:
- BALL.git: The main repository containing official branches. The most important branch here is the master branch. All development should happen against this branch. The used SCM Git provides means to track the current status of this branch. Merge errors which arise due to not following this branch closely are the fault of the respective developer.
- BALL_devel.git: The unofficial development repository which can be used to publish unfinished feature branches internally. It is not recommended to develop a new feature against any branch in this repository. The policy on how these branches are maintained is decided by the branch creators. Hence complete history rewrites and breakage of tracking branches is to be expected.
As mentioned above the development process is centered around the master branch. This branch is always stable in the sense that only regression free changes and bugfixes as well as sufficiently tested features are allowed to be committed to this branch. Starting from version 1.4 new versions will be snapshots of this branch.
A short description of BALLs release and version number policies are given here. BALL versions consist of 4 numbers a.b.c.d, generally called major, minor, patch, and bugfix version number. The version numbers are incremented depending on the commits which have accumulated in the master branch.
- Bugfix: This number is incremented when only urgent bugfixes have been committed that must be released as soon as possible. Bugfix commits are:
- Regression free
- Well tested
- Small (Usually one or two liners)
- Do not introduce new features
- Patch: The patch level is bumped whenever a sufficiently large amount of stable new features and bugfixes has accumulated. These commits must fulfill the following requirements.
- Regression free
- Unit tests, python bindings and documentation are mandatory
- Good code quality is very important
- Minor: Whenever a new feature changes the behavior of already existing features such that the relevant parts of the documentation need to be rewritten it is appropriate to bump the minor version.
- Major: Large architectural changes and larger new features that drastically change the appearance of BALL and BALLView warrant an increase in the major version.
- Regression free: A commit introduces a regression whenever it breaks a unit test, leads to bugs and crashes in existing features or requires the user to reread the documentation of an already existing feature in order to understand the change in behavior. Generally every change that alters existing API is not regression free.
- Well tested: A commit is well tested if all unit tests pass and its correct behavior has been assessed in multiple use cases. If no existing unit tests cover the added code, these unit tests must be supplied by the developer.
BALL has no explicit project maintainer, administrator, or leader. Currently the decisions are made by a group of core developers. For discussion of these decisions please use the existing mailing lists. Also the core developers are reserving their right to revert commits that do not adhere to quality standards or the above criteria without prior notice.