Currently we release at a Component level, e.g. RM 1.1.0, AM 2.2.0 etc. We don’t currently have a full ‘platform release’ mechanism. To take care of e.g. RM 1.1.0 needs at least BASE 1.0.4 or similar.
NB: general idea of the components in openEHR was to be loosely coupled, and have limited version inter-dependency.
Thomas Beale : possibly implementable with Github submodules. But how to define the platform release baselines? [But: really needed?]
Sebastian Iancu really needed? If can be avoided, … better approach is per-component, dependencies list, i.e. min; other UC: AQL could rely on a min RM release, to allow tags & folders, which are new/modified
Seref Arikan take a conformance testing point of view - what works with what?
AGREEMENT: don’t require whole-of-openEHR ; need a limited dependency list/tracking per version of each component; ideally shown on the specs website on release table view.
also add in subsection to Preface of all? some specs that have dependencies.
Seref Arikan - OpenAPI mature enough yet? BUT: could OpenAPI function as BMM alternative? For data only, possibly.
Sebastian Iancu - still more mainstream as a spec technology (APIB probably dying), even if code generation not quite working (particularly polymorphism)
Note: FHIR maintains 2 XSDs one for code-gen, one for spec-representation
Ian McNicoll - don’t bother with canonical RM complexities and support only web template formats? (TB: probably true for 85% of devs).
Thomas Beale arguably 3 levels of representation - maybe only last 2 relevant for APIs:
full canonical RM etc
simplified RM
web template formats
Issues:
relationship between REST API release and releases of payload, i.e. RM, AM etc.
Tips and Tricks
Hackers' Corner
Next SEC call
Outstanding topics:
Agenda items:
Notes
Action items
ALL - nominate in-house experts from your org for addition to SEC Expert Panel