Best practices

This is a set of best practices for IzPack developers and contributors.

It tries to be normative without putting too much bureaucracy in the processes.

General rules

1. Be friendly. The IzPack community has always been like that and we don't want that to change!
2. A new feature must always be documented, else there is no point in adding it!
3. Major enhancements must be proposed and discussed via IzPack Enhancement Proposals.
4. Any fix or enhancement must be attached to an issue from our JIRA instance at http://jira.codehaus.org/browse/IZPACK (this allows proper planning of the releases as well as generating complete and meaningful release notes).

Please keep in mind that most IzPack developers are volunteers that are not paid for developing it. We do it for fun on our free time, so please don't expect the same level of support as if we were a company (but we're doing our best to be as close to that as possible ).

Rules for developers

1. Use meaningful comments when doing a Subversion commit.
2. When doing a commit based on a patch from a contributor, make sure to mention the contributor name in the comment.
3. Never commit incomplete changes (Subversion is not a backup system).
4. Working on experimental changes is encouraged, but in this case use a branch.
5. Like anybody else, use IzPack Enhancement Proposals and our JIRA instance.
6. Don't maintain Versions.txt anymore, we will extract release notes from JIRA starting from IzPack 4.0 and beyond.
7. You may do a commit without a related JIRA issue, but make sure you have a very good reason not to do so.
8. Subscribe to the SCM mailing-list to get notified of SVN commits and JIRA activity.
9. Do not hesitate to pick new JIRA issues: both the other developers and the issue submitter will thank you for the work!

Rules for contributors

1. Always create a JIRA issue.
2. If you have a patch, then attach it to the JIRA issue.
3. Make sure you send a real diff-generated patch, not whole files or ZIPs with the modified files...
4. Should you propose a new feature, make sure to attach documentation. Ideally you will have a patch for the documentation, but plain text will also do.
5. Should you propose a major feature, file an IzPack Enhancement Proposal as well.

Code formatting

Everyone has its own preferences, so to make everyone comfortable, here are a few things to respect.

The preferred style is ANSI-style, i.e., we prefer:

if (i == 0)
{
    doThis();
}
else
{
    doThat();
    andThat();
}

over:

if (i == 0) {
    doThis();
} else {
    doThat();
    andThat();
}

of even this:

if (i == 0) doThis();
else {
    doThat();
    andThat();
}

You may prefer putting braces on end of lines rather than on new lines, but in this case please don't be feel offended when we run code formatting from times to times

You should avoid long width lines. 80 characters is probably short nowadays. 100-120 characters looks like to be a good limit.

After IzPack 3.11.0 we will use Java 5 as the language source and target version. We will generate a Java 1.4 compatible version using Retroweaver.