Bug Checking Process

Principles

Bugs will be divided into the following categories:

• Defects
• New Feature

All defects will have the following prefix in the bug title:  "DEFECT:".  For example: 0008861: DEFECT: index rtf files

All other bugs are considered new development.  For example: 0008860: Print to pdf: Should take a path to a custom stylesheet, also support html output mode for debugging

Techniques

Bugs categorized as defects will be applied first to the latest stable branch (ex: /public/dekiwiki/10.0).  After commiting the change to the stable branch, changes will be forward ported to the trunk branch (/public/dekiwiki/trunk).

Bugs categorized as a new feature will be checked into the trunk branch (/public/dekiwiki/trunk).  Feature bugs will NOT be backported into the stable branch.

ChangeLogs

A ChangeLog file will be maintained for each branch.  This file will exist at the root of the branch (ex:  /public/dekiwik/trunk/ChagneLog).  As part of each checkin, the ChangeLog file will need to be modified to specify the change made for the current checkin.

TODO: Define the exact format of the ChangeLog file.  The final ChangeLog format is TBD.  Developers can continue checking in changes as normal and PeteE will review the SVN log to create the proper ChangeLog entry once the format has been finalized.

Releases

At the end of each 2 week iteration, a determination will be made whether the iteration will result in a release candidate for a major release or a point release of the current stable release (or both).  The SVN revision number of the last change in the itreation will be captured and communicated to the community (via a blog post).  Customers or community members who wish to run the latest iteration will update to the provided revision number in our SVN tree (ex: updateWiki.sh -r 12345).