OBJECT_VERSION_ID typos in format

Description

http://openehr.org/releases/RM/latest/docs/support/support.html#_object_version_id_class

object_id ::' creating_system_id ::' version_tree_id

There are other formats with the same problem, a missing '

Environment

None

Activity

Show:
Pablo Pazos
November 27, 2017, 4:34 PM

IMO this is not a change of the specs, but a type correction on the HTML version, maybe an issue caused by the HTML export tool. The PDF version doesn't have the issue, it appear as:

object_id ‘::’ creating_system_id ‘::’ version_tree_id

Thomas Beale
November 27, 2017, 4:53 PM

It's actually caused by wrong text in the UML tool documentation, which is extracted to .adoc files, then processed by asciidoctor to end up in the HTML. It's not a semantic change of course, just a typo level change, but even those cause a patch level version in the current publishing framework.

In theory we could create a 'build' level of versioning (i.e. a 4th level) to take account of issues like this; it isn't that hard to do with Git branches, and moving the tag, but we'd have to write smarter server-side scripts to look for branches off tagged versions, or some similar approach, in order to automate the extraction of updates to existing versions.

Pablo Pazos
November 28, 2017, 6:02 AM

I don't think we need to release a new version to fix a typo of 2 characters due a problem on the export tools. In general I don't think it's a good idea to constraint too much or over-engineer our process because of bugs on exporting tools.

But I don't know of any server-side scripts and how those look into branches, or how are we managing branches, tags, releases and milestones on github (after the discussion on Slack I'm not sure what was decided).

Thomas Beale
November 28, 2017, 9:40 AM

It's not so much that we need a new release for typos (although that is what we did in the past), it's that there is a pile of scripts, webhooks etc that make the server-side publishing work. They rely on a certain style of release tag in git repos, and they don't currently search branches for release updates. We could change the rules on how branches and tags are used, and then upgrade the scripts to make them more sophisticated. It's a question of time, mainly.

Sebastian Iancu
November 6, 2018, 12:04 PM

this looks like fixed (1.0.4)

Reporter

Pablo Pazos

Labels

None

Components

Affects versions

Priority

Major
Configure