Codeline Policy

Synopsis::Provides developers with information about to which codeline their code should be committed and when it should be committed.

Intent
Development using multiple codelines requires a means to communicate clearly the intent and purpose of each codeline.

Motivation
When running developments using multiple codelines it is common for developers to misunderstand which codeline they should be working with.

Applicability
All developments that employ multiple codelines.

Also known as
also known as::Policy per Codeline

Structure
Codelines should be assigned meaningful names, one that summarises the codelines purpose. This is perhaps the most useful point solution and implies that any tool you are using to control your codelines should support codeline sensible names.

While a good codeline name summarises its purpose and is a necessary part of codline policy, it is seldom sufficient to communicate the finer points of the codeline's application. To communicate the finer points the following are useful.
 * Summary information. This should be readily available (on an intranet, preferably associated with the tool that supports the codeline in such a way that developers can locate it easily—a simple mechanism to support this for most tools is a README at the root of the codeline). This summary information should provide, in a concise 'bullet point' manner, the following information.
 * The associated project or work-packet
 * The codeline owner (the person to whom users can refer for clarification of codeline policy)
 * The codeline's submission policy (when should code be submitted)
 * Formal documentation (use with caution, you don't want to be overly bureaucratic) containing the following information.
 * All of the information from the summary (above).
 * Access restrictions that apply to the codeline
 * Relationships to other codelines—import/export relationships, merging (or anticipated merging), any ordering constraints on propagation to other codelines (refer to other branching patterns for details).
 * Codeline lifespan details (how long will this codeline persist, what conditions must be met for codeline retirement)
 * Ancillary codeline commitments and their schedule (how often will the codeline undergo integration, who is responsible for this work, when will it be carried out, etc.)

Not all codeines will require all of this detail (although it is highly recommended that those codelines that do not require some of these details still contain sections in the formal documentation that contain a 'Not applicable' entry to show that the issues have been considered).

Formal documentation can be held in the codeline (see Self-Documenting Codeline) or in a central repository (a project library, central document store, wiki, Intranet site, or similar facility).

Consequences
Codeine has a purpose that is clearly communicated and readily available to all stakeholders.

Known uses
Many projects running parallel development.

Related patterns
The following patterns are variants of the pattern.
 * variant pattern::Self-Documenting Codeline
 * variant pattern::Codeline Conventions

The following patterns are related to the pattern.
 * related pattern::Codeline Ownership
 * related pattern::Policy Branch
 * related pattern::Restricted-Access Line