I wondered about the release process for spec changes. Has it been described somewhere?
what I’m missing is, what is the status of a release? E.g. RM 1.1.0 is it released?
and why are many changes bundled into a release instead of releasing every accepted change straight away?
And how does voting on a proposed change relate to a commit? It now feels al though commits are made (and show up on specification.openehr.org) before they are accepted according to SEC ToR.
And are GitHub PRs an undesirable way to suggest changes? I’ve made a few for small typos. But find them open for some time already.
Release process: Release Strategy
The release process we follow is pretty standard in the software world: you create a number of change requests, you assign them to different releases; each release then consists of some particular set of changes. We do those changes, and then indicate in a) the Amendment record and b) Jira rthat the release has been done, and what CRs and PRs were covered by it.
And how does voting on a proposed change relate to a commit?: theoretically we should make changes on branches, and commit those, and then votes would cause the change to be merged to the master branch. The problem is that doing branch-and-merge relies on all the files being mergeable, and that is not the case for a) diagram files or b) UML files. So instead I have historically done the changes on the master branch so as to ensure all changes to the UML files are coherent. I'd much rather do the branch and merge workflow, but I don't see a way around the UML file problem (unless we ditch tools like MagicDraw and move to Borut Jures' approach).
Have a look at a component release page and you'll see how the CRs are linked to the release, and how they are shown in the amendment history of each spec. openEHR - Reference Model (RM) Component - 1.1.0
So I discovered the status of a release on Jira: Versions - openEHR JIRA
So for example this CR [SPECRM-107] - openEHR JIRA
It’s closed and accepted. It has commits associated Adjustments for SPECRM-107 - improved version content lifecycle; upda… · openEHR/specifications-RM@350d016 · GitHub
But the CR is part of release 1.2.0 which is ‘unreleased’.
(Although the affected version implies it’s part of 1.1.0?
)
And the changes don’t show up on Common Information Model
So how does the CR relate to GitHub commits, and how do the commits to text on the spec website?
Ah apparently there’s a release and a development baseline. The commits do show up on:
Common Information Model
And the baseline can be chosen here
I think this could be clearer. And is it somewhere explained how this works? Release Strategy
This didn’t say much on the different baselines, or I’ve misread.
Aah, apparently there’s also an option to pick ‘latest’ from a spec component.
Now that I understand it all makes sense. But it’s a little hard to understand if you’re starting from scratch. But maybe that’s ok, since most people should be working from the ‘release baseline’ I guess.
The release date is apparently set before the actual release is released.
Now, is the release data in actually released releases reliable?
Could you help me understand this problem better, uml files are produced by magicdraw as .mdzip binary files right? I understand Git(hub) cannot do git diff on the contents (and thus the actual changes) of the file. But it it’s still possible to do change control from branch-PR-Review(votes)-commit to master/main by deleting the old file and adding the updated file, right?
We progressively resolve and close CRs as they get done. When they are all done (in a release) we declare the ‘release’ publicly, on Jira and so on.
‘affected version’ means what version is being fixed by this CR?
‘fix version’ means what version is this CR actually in?
That sometimes happens, but it gets fixed when we actually do the release on Jira.
1 Like
The date of a “prepared” release gets fixed once is actually released - in the meanwhile is is just a kind of proposal target.
To explain a bit more, right now for RM:
- the last stable release is 1.1.0 on 29-Sep-2020
- what we are now working on is considered “latest” and planning to be 1.2.0, which at this time is planned for 2023-06-30
- the “latest” contains SEC reviewed-and-voted (accepted) changes, as well as not-yet-reviewed changes (yes, debatable if this is handy)
- the “latest” can be considered a release-candidate, which is quite often named on specs website (as a future release, or a unreleased releases)
- once 1.2.0 it going to be released, it will not going to be changed content-wise anymore, and will be addressable via url containing “Release-1.2.0”, and any future changes will be part of a future release (e.g. 1.3.0), which for a while will be aliased as “latest”.
In any case, this flow might not be perfect, and is possible to be changed if we consider it as unhandy. It was also discussed and mentioned in a few SEC meetings lately.
1 Like
