...
Lifecycle State | Period | Publication Format | Versioning* | Change documentation | Change Manager | Issue Reporting | Formal Expression | Implementation Technology Specification(s) | Implementations | Conformance |
|---|---|---|---|---|---|---|---|---|---|---|
Development | 18 months max | Wiki; PG writable | 0.y.z | Change Requests optional; otherwise informal | CMG or external development group | Informal | One formal tool-based expression must exist, in a widely recognised format, prior to promotion to trial state. | At least one ITS must exist prior to promotion to trial state. | one open source reference implementation must exist prior to promotion to Trial state. | n/a |
Trial | 2 years max | Wiki??; PG writable | x.y.z | Change Requests | CMG | Problem Reports | Tool-based expression maintained. | Ideally two ITSs should exist prior to promotion to stable state (where multiple technologies are in routine use). | Prior to promotion, at least 2 independent interoperating implementations, preferably in different major technologies at end of period. These may be commercial or open source. | Conformance levels & criteria developed, tested and published. |
Stable | unbounded | Durable high | x.y.z | Change Requests | CMG | Problem Reports | Tool-based expression maintained. |
| Reference implementation maintained. | Industry implementations recognised via conformance testing. |
Obsolete | unbounded | Replaced by | frozen | n/a | EC | n/a |
|
| Reference implementation still available but not maintained. |
|
Superseded | unbounded | Replaced by | frozen | n/a | EC | n/a |
|
| Reference implementation still available but not maintained. |
|
* Versioning obeys rules of semver.org; note that version 0.x.y versions do not follow any strict rules.
TBD: Possible variants:
- publish in durable format for Trial period; wiki is truly bad - non-standard, very poor display quality, and editing on most wikis in WSIWYG is truly abysmal.
Problem Reports (PRs) can be raised by anyone, and are designed to capture reports of problems and issues, including new requirements. Change Requests (CRs) can be created only by the Specifications group, and are used to document changes undertaken to the specifications. No change can be made to the specifications without a CR.
...
- a short description (i.e. title)
- a description of the problem(s) it addresses, and/or references to relevant PRs
- the associated component within the specification library.
- if more than one component is affected, a separate CR or Task is created for each component
- the raiser
- Other key fields such as id, date etc are created automatically.
TBD: we don't actually do this now; currently, more than one component can be affected by one CR. This is actually better CM practice...
Acceptance
Every CR has to initially be accepted or rejected by the EC. This primarily means determining if:
...