Development

Development cycle

The development process shall be as transparent as possible. The objective is quality, not speed.

Phase 1 - Planning / Design

First interfaces are defined. This should be done with great caution, because it will be fatal to change the interfaces after the files have been released. After the interfaces are specified, test criteria to verify a correct implementation are defined. Finally the individual tasks are prioritized. The planning should contain auxiliary artifacts such as web pages, tutorials, etc. This phase may include public announcements to send proposals, PR actions and surveys, among others.

Phase 2 – Development

The tasks of phase 1 are assigned to developers and the code and documentation are written. Once the code has reached maturity and meets the test criteria, it can be forward to testing.

Phase 3 – Testing

Testing includes the online community. In fixed interval (let’s say one month) a test version or beta will be released. If bugs are reported, the corresponding component is rejected and reenters the process in Phase 2. If the component passed the testing interval without any bugs, it is added to the trusted code list.

Phase 4 – Releasing

Official releases occur whenever a previously milestone has been reached. Since this may take some time, there will be a mail list to announce which components have made it into “trusted code” stage. People who are waiting for a particular component can subscribe to this list and will be notified prior to a major release.

The release will include the sources, in order to avoid the trouble of different JDK versions.

Phase 5 – Auxiliary Documentation

After releasing the files, tutorials and sample programs are published.

There will be different modules in the CVS to ease distinguishing experimental and trusted code.

Code Guideline

Generally the Sun style guide applies. In addition we want to enhance the level of comments and the quality of documentation. There shall be JavaDoc comments for all methods, including protected and private ones. There should be sufficient documentation to understand the code. A first suggestion would be to have a comment at least every 10 sequential lines of code and an explanation whenever a condition has more than 4 atomic decisions. Commits to the CVS must contain detailed descriptions of the changes made.

Native or platform-dependent code must not be used. Code that demands a particular version of JDK shall be avoided whenever possible.

Modifications

There will be a quarterly review of these guidelines and they will be modified if necessary or appropriate. The modifications will be discussed by the admins and by people who will be strongly affected by the changes. There will be an ad-hoc change if an immediate demand arises.