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:
- 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
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.
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.
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.
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.
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.
- 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 CRs can be viewed 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.
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.