openEHR Specification Project
Release Strategy


Release Identifiers

With the advent of Release 1.0 of openEHR, more rigorous change management rules come into play. These are designed to protect developers and users from adverse effects of changes, and to allow them to upgrade in an orderly fashion. Future releases will follow a 3-digit numbering scheme similar to many open source projects, e.g. Apache, using identifiers like 1.0.1 etc. The meaning of a change in each digit is as follows:

Changes to Documentation

Where changes to documentation are made, e.g. due to a request to clarify an explanation, fix a typographical error, a CR will be raised, and the revision number of the affected document(s) will change, but there will not be a new release number.

Error corrections

Where the changes made are to correct an error in a model, parsing rules or some other aspect of the formal semantics of the specifications (and possibly accompanying changes to explanatory text), an error-correction release will be made.

Compatible Additions

Where the changes have the effect of adding a new specification or other artifact which is completely compatible with the current release, an enhancement release is made.

Major Changes

Where changes actually alter semantics of existing artefacts (other than for minor error corrections), a new major release is declared. Such changes would normally be grouped into as few such releases as possible.

Change Management

As with pre-1.0 releases, change management will remain a disciplined process.  Two types of online document, the Problem Report (PR) and the Change Request (CR),  are used to track problems and changes. These are used as follows:
From Release 1.0 onward, the way CRs  are processed will change slightly. All changes to the specifications, apart from document text changes (e.g. improving explanations, fixing typos) will be signalled to the community via the openehr-technical mailing list, and a period of time given for the community to inspect the proposed changes and provide feedback. This is particularly aimed at allowing implementers to indicate the knock-on effects of changes. In the process of such discussions it may turn out that the proposed change will not go ahead, or that it will go ahead in a later release than originally planned. In this way, the community will be able to ensure that releases into the future remain stable and occur at a reasonable rate.

All changes in the Release 1.0 mainline must also be implemented in at least one instance of software, schemas or other appropriate formal expression before being accepted as a change to the specifications.

$LastChangedDate: 2007-02-28 12:07:12 +1000 (Wed, 28 Feb 2007) $ $LastChangedRevision$