Development policies

Line endings

Proper handling of line endings is very important! We don’t want to get diffs on every line just because someone checked in CRLFs…

Any submitted patch that has line endings problems will be rejected automatically!

Please make sure that you set your core.autocrlf setting properly: git config --add core.autocrlf input on Linux/OSX, git config --add core.autocrlf true on Windows.

Code formatting and cleanup

Please set up the Java formatting to the Eclipse default. For CleanUp and SaveActions, please use

Change non static accesses to static members using declaring type
Change indirect accesses to static members to direct accesses
Remove ‘this’ qualifier for non static field accesses
Remove ‘this’ qualifier for non static method accesses
Convert control statement bodies to block
Add final modifier to private fields
Add final modifier to method parameters
Remove unused imports
Add missing ‘@Override’ annotations
Add missing ‘@Deprecated’ annotations
Remove unnecessary casts
Remove unnecessary ‘$NON-NLS$’ tags
Remove trailing white spaces on all lines
Correct indentation

Commit policies

The rules are not set in stone (yet :-)), we’ll change them as we gather more experience.

Development codeline (pu and later branches):

• interim code changes may be checked in;
• affected components must be buildable.

Release codeline (next branch):

• software must build and pass regression tests before check-in;

Mainline (master branch):

• all components must compile and link, and pass regression tests;

These policies are for the official repository, of course. You can work in your own repository as you like, the only rule is that you are responsible for making all patches to apply cleanly on the official repository. The maintainers retain the right to refuse to apply anything that creates merge problems.

Versioning

Please note that as we approach version 0.9, the next one after it may well be 0.10 and not 1.0. We have not decided about that yet.

work in progress, not decided yet

As from version 0.8 we use the following version number system (examples from Cairo):

We use a four-part version number scheme. In this scheme, we use even vs. odd numbers to distinguish fixed points in the software vs. in-progress development.

 _____ major. 
/  ___ minor: even = release; odd = snapshot.
| /  _ micro: even = stable; odd = unstable.
| | /  qualifier: is a timestamp and may contain other info (to be defined later)
| | | /
1.0.0.qualifier

Here are a few examples of versions that one might see.

Releases
--------
1.0.0 - A stable release
1.0.2 - A subsequent maintenance release
1.2.0 - Another stable release
.
Snapshots
---------
1.1.2 - A snapshot (working toward the 1.2.0 release)
.
In-progress development
--------------------------------
1.0.1 - Beta testing on the future 1.0.2 release
1.1.1 - Beta testing on the future 1.0.2 release