Management policy for inid CVS repository (2000-05-22) This document shows development and management policy for inid and its CVS repository. [Version Numbering Scheme] **Official Release: on the main trunk inid 1.01 (tag name: inid101 ) inid 1.02 (tag name: inid102 ) inid 1.03 (tag name: inid103 ) : : **Developing Versions: ("-current" version on the main trunk) inid 1.01 (official release) inid 1.02p (between 1.01 and 1.02) inid 1.02 (official release) inid 1.03p (between 1.02 and 1.03) : A committer who modifies an official release of the source code into developing version must also update the version number string written in a header file. [Management Policy of Source Tree] 1. Assignment of maintenance responsible persons Current Assignments: - core part : taka (NAKAMURA Takayuki) - inidwin : noraneko (TAKESHIMA Hidenori) - configure : yutaka (OIWA Yutaka) A responsible person is assigned for a part of inid source codes. The responsible person has an actual initiative for implementation and management decision of the assigned part. Persons who implement and/or frequently update any part of inid will be naturally responsible persons. A responsible person may commit any modification in the responsible part to the main trunk of the CVS repository. Although compiling check had better to precede the committing, it is not a duty. Other persons who create patches may send them to the responsible person. The responsible person may or not merge the patch. Each responsible person freely decides detailed management policies for each responsible part. The following policies are only for Taka's responsible parts. 2. Committers may create a new branch in the CVS repository. A branch had better to be from an official release version. A branch that starts from the version 1.xy should have the branch name of "INID1xy_FOOBAR". A committer may also create a branch from "-current" version when "-current" is far from the previous official release. The name of the branch should be "INID1xyP_FOOBAR". Committers should read the inid coding style guide (style.txt). 3. Committers may commit their modifications to the main trunk, if they satisfy all of the following requirements: Requirement 1. Test your code before committing. Your code must be able to be compiled on your environment, as a minimal requirement for testing. Requirement 2. Follow the inid coding style guide. Requirement 3. Degrades are not allowed. All features must be alive. Requirement 4. If your modification is for bug fixes or obvious extensions of features, you can commit it freely. Requirement 5. Else, discussions are needed in the developers' mailing list before committing.