Revised Coding Guidelines

Redirect to:

• Coding guidelines

	This function is deprecated. This means that its use is discouraged and that it might not exist in future versions, but there should be a more generic way to perform what it does.

This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase. It also covers related aspects of the development process such as nightly builds.

The trunk, and branches

• The trunk will be used as the main development codebase for the forthcoming release. In this case it would be 1.0.1
• A branch will remain for each stable release. The 1.0 branch will remain so that servers can continue to be compiled for each version
• Branches are also used for experimental work, or anything that will not be included in the forthcoming release, or that needs to be tested thoroughly before being included in the forthcoming release

Nightly builds

• As before, there are only one set of nightly builds. These are compiled from the trunk and represent the forthcoming release.

Actual coding guidelines

• Any negatively reviewed commits with a justified reason should be reverted, or corrected in a future commit as soon as possible.
• Positive reviews may be given but they have no effect on the structure of the codebase.
• Developers are allowed to commit any changes directly to the trunk, as long as they meet the following conditions:
  • They are not experimental
  • They are intended to be included in the forthcoming release
  • They do not need thorough testing before being stable.

Obviously these guidelines are vague, and developers should use their own judgement to decide what is acceptable and what is not.

The build up to release

Depending on the stability of nightlies, and the structure of the codebase an "Airtight" system may be employed in order to ensure a stable release. This is an adjusted version of the +4 coding guidelines - all commits must receieve 4 positive reviews to be approved, otherwise they are reverted. This process may or may not be applied, but can be used when in Release Candidate stages to ensure no unstable code is added.

Community involvement

Though this has not been decided, it may be useful to enable a community review system. This essentially allows the community to provide reviews on every commit. As with developers, positive reviews may be given but have no effect. Negative reviews, if valid, should be accounted for in an equal manner to if a project developer gives a negative review.

• Community ratings will undoubtedly require moderation, but this extent of this is unknown till it is tried.
• During an "Airtight" phase, community ratings will have to be disabled.

Bear in mind that community ratings is not a requirement for the new coding guidelines, but may work in our favour if used properly.