ARCHIVED - Version Identification Procedure

This page has been archived.

Objective

To define the release, item and document numbering system for versions and variants of configuration items.

Scope

All baseline items (including source files, build files, object modules, releases, and technical specifications) will conform to this procedure.

Unapproved (viz. draft) items not yet under configuration control (e.g. prototypes) need not conform to this procedure. In such circumstances, this procedure should be used as a guideline.

References

CM030 Change Control Procedure

CM012 Change Management Handover Form

Outstanding Issues

None.

Approvals

Development Manager.

Responsibilities

The Project Manager is responsible for the application of this procedure to the relevant project.

The Project Manager has the final decision over the allocation of an identifier on all configuration items, provided that they conform to this procedure.

The project team is responsible for the implementation of this procedure.

The Configuration Librarian is responsible for ensuring that all configuration items within the library conform to this procedure.

Inputs

Unidentified items.

Outputs

Uniquely identified items.

Control Mechanisms

Independent audits check for compliance against this procedure and propose process improvements.

CM Handover Forms used when submitting items into the CM (Configuration Management) Library, are checked by the Configuration Librarian.

Retrieval and access to configuration items in the CM library demand use of version identification.

Use of project deliverables within the development life cycle ensure that configuration items are identified.

Procedure

General

The project team assigns unique identifiers to items which come under configuration management as described in the paragraph on Item Identification below.

The Project Manager assigns unique identifiers to baseline releases (and also any interim upgrades) as in the paragraph on Release Identification.

The Project Manager may, in addition to the version identification defined in this procedure, optionally also date/time stamp items and releases.

Item Identification

Each item has a file name, unique to that project, as per the paragraph below on File Naming.

Each item includes change history as defined in the Change Control Procedure.

Each item has an associated version identifier, which takes one of two forms:

i. an integer number, with the initial baseline version starting at "1", and incrementing monotonically.

ii. a decimal identifier of the form described under Release Identification e.g. for use when documentation is associated with a product release.

Items should not swap between the two forms.

There need be no correlation between an item identifier and a release identifier.

Each item may optionally have associated with it:

i. an item description

ii. a creation or purchase date (or cross-reference)

iii. a reason for the creation/purchase (or cross-reference)

Variants are additionally identified as in the Variant Identification paragraph below.

Unapproved (and draft) documents and prototype systems are clearly marked as such.

Each user document has a title, file name, and identifier assigned, as defined in the Document Naming paragraph below.

Variant Identification

Wherever possible, variants are not stored separately. This is achieved by use of conditional compilation, build scripts, etc.

When storage of variants within one file is not possible, a manual system of cross-reference between variants is maintained by the Configuration Librarian. This is documented in a work instruction.

When a variant is released into the configuration library, the Configuration Management Handover Form contains all relevant information to identify the associated variants.

Release Identification

A release in this document is defined to be a combination of files, which together become a configuration item.

All releases will be identified in the format: M.F.I, where the fields are:

M Major feature update, starting at "1"

F Minor feature or bug fix, starting at "0"

I Internal upgrade, starting at "0".

e.g. Release 2.1.0.

These fields are numeric and increase monotonically.

The internal field may be dropped when communicating external to Department X.

Patches may be issued, for example as part releases, and are denoted by the addition of a letter to the F or I field. E.g. Patch 2.1A.0.

Releases are built from a combination of configuration items, which themselves have version identifiers (see above). The Configuration Librarian maintains a record of the configuration items (and their versions) which comprise a release.

Document Naming

Document Title, File Name, and Identifier

The author drafts a title for the document in line with the style defined below.

The author assigns a file name and allocates a unique document identifier, in line with the conventions defined below.

The Configuration Manager approves the use of the file name and identifier.

The Configuration Librarian maintains a list of allocated file names and identifiers, along with the corresponding titles.

File name

User documentation have file names corresponding to pppttnnn.yyy, where

ppp = unique project number, allocated by the Configuration Librarian

ttnnn = unique identifier (q.v.)

yyy = file extension appropriate to the supporting package.

Identifier

Each document has a unique identifier of the form: ttnnn, where

tt = two letters related to the document title, as defined below.

nnn = index number, allocated by the Configuration Librarian.

Title

The following titles are provided as guidelines:

Item	Mnemonic	Title	Explanation
1	UG	User's Guide to....	Basic instructions leading users through a system
2	IN	Introduction to .....	A simple starter's kit to using a system
3	RM	Reference Manual for....	Alphabetic or other structured description of features/commands
4	TU	Tutorial for ....	Teaching instructions for a system
5	RN	Release Note for ....	Information on the content of a particular release

Additional titles can be used, with the permission of the Project Manager.

The name of the system/project must appear in the title.

File Naming

Each file within a project is assigned an appropriate, unique filename by the programmer/author responsible for that configuration item. The uniqueness of the identifier is checked by the Configuration Librarian.

Files which can be edited contain change history as defined in the Change Control Procedure. The additional naming convention described below may optionally be applied.

Files which cannot be edited have additional naming conventions:

i. The last two characters of the filename, not counting the extension, are used to illustrate the version number, e.g. x.y.

ii. The decimal point (if applicable) is omitted from the filename.

iii. Numbers greater than 9 are represented by alphabetic characters.

iv. For example driver32.doc represents version 3.2 of the driver file.

Source files which cannot be edited (e.g. some 4GL files) have an associated Change History file (see Change Control Procedure). These files have a ".chg" extension replacing the standard extension.

Associated forms

Configuration Management Handover Form, CM012.