Developer Gudelines

Here are some guidelines for developers which will help us to manage the project, and keep the quality of code and documentation:

1. Please do not put anything in core and nnet packages, instead use something like org.neuroph.contrib.yourpackage
   After review and testing when that code become stable, it may be moved to some more appropriate package.
   
   
2. Please put comments for classes and methods in your code so javadoc can generate documentation.
   
   
3. Use plugins (see org.neuroph.util.plugins) to create custom additional components which are not related to neural network architectures or learning algorithms.
   
   
4. Prefered tool for any GUI related development is NetBeans
   
   
5. Please follow the Java coding conventions and Javadoc comments style recommendations
   

SVN

The following are some excerpts from the "Continuous Integration" wikipedia entry that should be used as guidelines for maintaining Neuroph's SVN using the industry "best practice".

http://en.wikipedia.org/wiki/Continuous_integration

"Extreme Programming advocate Martin Fowler also mentions that where branching is supported by tools, its use should be minimised[citation needed]. Instead, it is preferred that changes are integrated rather than creating multiple versions of the software that are maintained simultaneously. The mainline (or trunk) should be the place for the working version of the software."

"By committing regularly, every committer can reduce the number of conflicting changes. Checking in a week's worth of work runs the risk of conflicting with other features and can be very difficult to resolve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making."

POLICY

The suggested policy for the Neuroph team to adopt is that all current code modifications are based on and committed to HEAD (the mainline). It is perfectly acceptable to commit "in progress" code to head at any time as long as it builds. Code contributors will either need to make themselves available to resolve conflicts or else risk having another contributor resolve it for them without their input.

Official releases are created by branching HEAD and naming the branch with a version number. The branch becomes a "release candidate" until it passes whatever testing the contributors need to do. Once branched, the release candidate should only receive bug-fixes and stability patches. No new development code should be committed there.

An implication of this policy is that there are 2 places in SVN that contributors are concerned with: HEAD, and the current release candidate branch. There should only be one "active" release candidate branch at a time. Any contributor who is working on "silo'ed" code in a branch should merge their work into HEAD and abandon their branch.