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-part 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 part is as follows:
- 3rd position: used to indicate error corrections and minor additions that do not change the semantics. Thus, Release 1.0.2 is the second error correction release after Release 1.0.
- 2nd position: used to indicate significant additions that do not change the semantics of the existing part of the release. Release 1.3.0 would be the 3rd release containing compatible additions to Release 1.0.
- 1st position: used to indicate changes to the semantics or large changes. Release 2.0 would contain changes incompatible in some way with Release 1.0, most likely requiring software upgrade and possibly data migration.
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:
- anyone can raise a PR to indicate some issue or problem with the current release. A PR documents the issue seen from the user's perspective, with the resolution being provided by the development team.
- only a member of the development team can raise a CR. All open CRs can be viewed here (completed CRs are here). A CR documents a change to the current release. A CR will either describe the problem it is solving, or refer to one or more PRs it is designed to address. The CR is a document of the change and the process of applying it to the release.
From Release 1.0 on, 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 on the Discourse site specifications category, 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.