Development Process¶

The high level view of the development is probably best explained by the following picture which includes also the quality management and the community involving processes. It is the ISO 9000 inspired Quality Management System used in the project.

For a better understanding of this development circle it is necessary to know the roles which are setup in the process of development.

Roles¶

The project comprises the following roles:

• User: This person has read access to the public git repository and to the download area for release packages. He is allow to submit bug reports and improvement suggestions. This subject is settled in the user community.
• Developer: A person in the role of a developer is here part of the developer community. The difference to a normal user is that the developer is involved in the programming of new features or the solving of bugs. Also he is responsible for developing the components that have been assigned to him in accordance with the project guidelines (see next subsection as well as the code-style guidelines) and the overall project architecture. He must also comment and document his code properly.
• Core Developer: The core developer is a project member which contributes regularly and is mainly involved in the development and extension of the application core. There is no other difference to an other developer so all rules applying to an developer are also relevant for a core developer.
• Tester: He should review the code of a developer and is part of the decision process about which commitments are accepted for the main code base.
• Manager: This person is responsible for creating releases in time. He must also make sure that a pre-release version is thoroughly tested by the tester before releasing it to the public. This should guarantee that a release is widely free of errors. The manager should also distribute new releases to the users and all other roles.
• Project Manager: The project manager is responsible for steering the entire project, collecting new features, evaluating them and assigning respective development tasks to the developers for realizing these features.

The Project Manger, Manager, Testers, and Core Developers form the core team which is responsible for development of application core. They may be assisted by developers from the developer community.
So now may want to know how the development process of a new release (minor or major release) is initiated and what's happening in the phases of the development. This will be the subject of the next sections.

Initiation Phase¶

On the very beginning there have to be defined what the development goals of a new release are. This includes evaluation of the feasibility of new features and the necessity to fix open bugs also the stability may be subject of decision process. In order to archive the goal definition the feature and bug trackers are considered to get an overview about what the needs of the community are to improve the acceptance and increase the spreading. Furthermore there is the core team which may have ideas they want to implement to simplify the internal structure or module communication or whatever. All the information are gathered by the Project Manager and discussed with the manager. In the end the features to implement and bugs to fix are transformed into tasks which are assigned to specific developers which are than responsible for the realization.

General Quality Assurance Guidelines¶

1. Only atomar commits should be uploaded to the repository. Each commit should not comprises more than 150 changed lines. If more changes are necessary, the upload should be separated in several commits.

   TW: I'm not sure if a max_line restriction is very sensible. Especially when adding new features, a lot of boilerplate code (class structure etc.) is being added, so the 150 lines rule can not be applied anymore. However I agree, that this makes sense for bugfix commits. In my opinion, the important points are.
   1. Commits must build.
   2. Commits should represent either a bugfix, an API change, the application of an API change, a cleanup/merge change, new features, the integration of new features, ... The important part is, that it is clear in one sentence (commit log) what happend.
   3. Commits should be as small as possible.
   4. Commits should be reversible without breaking the software. This is most certainly not true when changing shared functionality, therefore should.
   Perhaps atomicity is already the correct term, but we should mention the implications explicitly.

2. Untested code must not be committed. Each class must comprise at least a JUnit test. The new code must be in line with the current development code state and must be able to be compiled and run without errors.
3. Undocumented code must not be committed to the repository. Each code file must include proper comments according to the project style guidelines in Javadoc format.

A person is nominated by the project manager (usually a tester or release manager) who is responsible for supervising the commits of the developers and reject a commit if these rules are not obeyed.

Test Cycle¶

Benedikt could write how the individual developer can use jenkins to observe whether the code is ready for a merge request or not.
+ Other test related stuff

Release Cycle¶

1. Each release cycle lasts 8 to 12 weeks.
2. At the beginning of a release cycle, the project manager assigns the tasks which should be realized in this cycle to the developers. He also announces the planned release date.
3. At least 2 weeks before the release date, the release manager closes the current release branch (code freeze). Only error corrections may now be committed to this branch. New features must be committed to the branch of the next upcoming release.
4. After the code freeze, the release manager and the testers test the code thoroughly. If bugs are found, the developer who wrote the code is informed. The testers and the developer agree on who will be responsible for correcting the bug (tester or developer). It should then be corrected in 2 working days.
5. With the tests having been completed, the release manager builds a release version and distributes it to the users.
6. If a bug is detected in a release the release manager and the project manager decide whether its correction will be included in the next regular release or a bug-fix release is created. In the latter case, the release manager is the responsible for getting the bug corrected by the respective developer, getting the new version tested by the testers, building the bug-fix release and distributing it to the public.

The Software Lifecycle is documented in this wiki and a common work of all project participants

The release versions are numered in accordance to Semantic Versioning which is basically the following scheme:

• The first digit is the major release, starting with 1. The project manager decides when this number should be increased.
• The second digit is the release count, starting with 0. It is increased with each release and reset to 0, when the major release number is increased.
• The third number is optional. It is only given to bug-fix releases, starting with 1.
• Prior to major releases, a -rcX suffix may be used to create public testing (beta test) releases.
• Between all releases, the version must be suffixed with -SNAPSHOT, so that the maven repository can distiguish release and development uploads.

In addition to the code-style guidelines the project should furtheron be carried out according to a process model as described below.