This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Publishing from SVN

From HL7Wiki
Revision as of 20:59, 11 February 2009 by Astechishin (talk | contribs) (New page: {{V3 Pub Open Issue}} ==Introduction== This page is a description and discussion of the process for V3 Publishing where the source artefacts are stored within Subversion. ==Objectives== ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This page is a description and discussion of the process for V3 Publishing where the source artefacts are stored within Subversion.


  • Don (HL7 Publishing Coordinator) should be able to run publishing without direct intervention from WG or publishing facilitator
  • WG needs to 'publish' (commit/checkin/make available) without intervention from Pub Coord
  • Normative Edition is created once a year, compiled from previous NE materials and new successful ballots with minor rework (rework is one time affair)
  • WG wishes to continue work on artifacts while in ballot cycle.
  • WG wishes to be selective about contents of published ballot (current repository may contain more than the current ballot contents).


Scenario 1: WG submits document set for ballot

  1. WG creates base manifest (process from Woody) agreed
  2. WG edits manifest to reflect content ballot (or regenerates it)(on omissions, Need a status on artifactStatus table that says ignore this artefact for now)
  3. WG ensures that all updated files are committed to the main trunk.
  4. WG submits manifest for (what to) inclusion in ballot (check in? Checks in, informs pub-coord?) (I recommend that the manifest (name set for each ballot cycle) be checked in as part of the commitment. Ideally, the release number of the manifest would coincide with the release number to be published, although that may not be feasible. Certainly, the check-in process needs to notify the pub coordinator. One possibility would be to use G. Forge document release capability, which allows for people to subscribe to particular documents. In this case, the manifest would be the "released" document, and the Publishing coordinator (and any other interested parties) could subscribe.

Scenario 2: Ballot is Published (or a preview)

  1. Publishing Coordinator retrieves latest from repository (correction: the Publishing coordinator needs to retrieve the content based on the designated release number from the manifest, not the latest.)
  2. Publishing process runs using artefact specified in manifest.

Scenario 3: WG updates documents submitted for ballot

  1. WG synchronizes with repository (to ensure any updates are retrieved)
  2. WG performs edits on artefacts.
  3. WG commits updated artefacts to repository
  4. WG (informs publishing coord? Continuous integration engine?) (Here, I believe the publishing facilitator from the committee must submit a new manifest that asserts a latter revision number, corresponding with the commitment in step three.)

Scenario 4: Publishing Support updates files to produce ballot contents