...
{ "package-id" : "{pid}", "version" : "{version to release}", "path" : "{path}",
"milestonemode" : true "working" | "milestone" | false"technical-correction", "status" : "release", "sequence" : "Releases", "desc" : "{desc of release} (optional)", "descmd" : "{markdown desc of release} (optional)", "changes" : "{relative link to description of changes} (optional)", "title" : "{title} (only for first release)","ci-build" : "{link to ci-build location} (only for first release)", "category" : "{category} (only for first release)", "introduction" : "{intro} (only for first release)" }
...
- "package-id" : package id - for cross checking
- "version" : version to release - must match the version in the IG itself (cross-check)
- "path" : full url of where this release will live. Must be {canonical}/{code} - code can be the version, or something else
- "mode" milestone" : one of the values:
- "working": just public at the designated path, and don't update the current published version (if there is one). This is the default
- milestone: If this is true, this version of the IG will also be published to {canonical} as the 'current' approved version, (typically, this is considered the end of the sequence, though technical corrections are possible)
- technical-correction: update the current without making a new sub-path. The existing content at the sub-path will be preserved in a zip, but can no longer be found in google etc (HL7 policy is that this is only used for limited technical corrections with approval from TSC)
- "status" : the status of this release, one of release|trial-use|update|qa-preview|ballot|draft|normative+trial-use|normative|informative
- "sequence" : The name for the series of releases this is part of e.g. STU1, Release 1. This is how releases are grouped on the history page. If you don't have a sequence of grouped releases, just use Releases or Publications
- "desc" : Text description of the release
- "descmd" : Markdown description of the release (common mark). To make it easier to edit the markdown, you can put the value "@[filename.md]", and provide the markdown in raw format in [filename.md], a file in the same directory as the publication-request.json file
- "changes" : a link to a list of changes published as part of the IG
- "title" : The human readable name for the IG (for HL7 IGs: from the IG proposal)
- "category" : The category for the IG, for fhir.org/guides/registry - ask FHIR product director if unsure
- "introduction" : A human readable description of the intent of the IG (shown on the history page). For HL7 IGs: this is the long description from the IG proposal
- "ci-build": the location of the built IG on the build.fhir.org site or similar (typically using the FHIR Auto-publisher, a URL like http://build.fhir.org/ig/{org}/{repo}, found at https://fhir.github.io/auto-ig-builder/builds.html)
...