Stream: cds hooks/github
Topic: docs / Issue #291 May 2018 Ballot Comment 85
Github Notifications (May 16 2018 at 23:00):
cds-hooks-bot opened Issue #291
## May 2018 Ballot Comment 85
Submitted by @cmoesel from MITRE
Chapter: Hooks
Section: Hook version
Type: NEG :exclamation:
In Person Requested? NoExisting Wording:
When a major change is made, the hook definition MUST be published under a new name.
Comment:
If a hook name changes on every major version, what is the point of the MAJ slot in the version field? As written, it follows that the existence of Foo version 1.0 implies there can never be a Foo version 2.0. This isn't how I usually see semantic versioning applied, as it seems to defeat the point entirely.It seems it would be better to keep hook names consistent, but have services declare the hook and version they're implemented against -- and EHRs to send the hook and version in the CDS Service call. Due to semantic versioning, EHRs would know which services can support their version of the hook. Wouldn't that be more in line with typical semantic versioning practices?
## :de: Köln May 2018 Working Group Vote
@kpshek moved the following disposition, seconded by @isaacvetter.
Disposition: Persuasive with Mod
Disposition Comment:
We will keep major version changes to hooks as new hook names, but add guidance to name hooks with the version number (after 1.x) with "-2", "-3", etc. Eg: patient-view-2, patient-view-3, etc.:+1: For: 11
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
_This issue was imported by @cds-hooks-bot from the consolidated CDS Hooks May 2018 ballot spreadsheet._
Github Notifications (May 16 2018 at 23:00):
cds-hooks-bot milestoned Issue #291
Github Notifications (May 16 2018 at 23:00):
cds-hooks-bot edited Issue #291
## May 2018 Ballot Comment 85
Submitted by @cmoesel from MITRE
Chapter: Hooks
Section: Hook version
Type: NEG :exclamation:
In Person Requested? NoExisting Wording:
When a major change is made, the hook definition MUST be published under a new name.
Comment:
If a hook name changes on every major version, what is the point of the MAJ slot in the version field? As written, it follows that the existence of Foo version 1.0 implies there can never be a Foo version 2.0. This isn't how I usually see semantic versioning applied, as it seems to defeat the point entirely.It seems it would be better to keep hook names consistent, but have services declare the hook and version they're implemented against -- and EHRs to send the hook and version in the CDS Service call. Due to semantic versioning, EHRs would know which services can support their version of the hook. Wouldn't that be more in line with typical semantic versioning practices?
## :de: Köln May 2018 Working Group Vote
@kpshek moved the following disposition, seconded by @isaacvetter.
Disposition: Persuasive with Mod
Disposition Comment:
We will keep major version changes to hooks as new hook names, but add guidance to name hooks with the version number (after 1.x) with "-2", "-3", etc. Eg: patient-view-2, patient-view-3, etc.:+1: For: 11
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
_This issue was imported by @cds-hooks-bot from the consolidated CDS Hooks May 2018 ballot spreadsheet._
Github Notifications (May 16 2018 at 23:00):
cds-hooks-bot labeled Issue #291
Github Notifications (Jun 14 2018 at 13:41):
cds-hooks-bot assigned Issue #291
Last updated: Apr 12 2022 at 19:14 UTC
