Documentation for developers

Read the following rules before starting to contribute/code.

Management Documents

For more information browser our SVN.

SVN commit politics

Since code commit implies the code quality and stability, the ANKOS project define some politics for new developers and ANKOS official members.

First, if you are new on ANKOS project, probably you won't have permission on doing commits. So, your code contribution must be approved by some ANKOS developer members before inserting it in the main development line. As soon as your aproved contributions quantity increases, you may become an ANKOS developer member, and your code can be directly commited.

SVN best practices

Commiting well defined changesets

Since your commit will create a new version number, is hardly recommended that you only commit well defined changesets. It means that you must commits code that achieved a single purpose: fixing a specific bug, adding a new feature, etc.

Linking bugs on your commits

Always try to link your commit to the issues ID in the tracker database. Also, when closing the issue on the tracker, try to put the revision number that resolved the issue. Note that it is possible only if you follow the Commiting well defined changesets strictly.

Track merges manually

Before committing the result of a merge, be sure to write a well descriptive log message that explains what was merged, something like: Merged revisions 3490:4120 of /branches/foobranch to /trunk.

Branching

The politcs for ANKOS source branches is Branch-When-Needed system. It menas that developers commit their day-to-day work on /trunk. And, only when it makes sense, is created a branch.

Tagging

The politics for ANKOS source tagging follow the O3S Process. It means that is created a release for the users in each interaction phase.