Publishing from SVN

Introduction

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

Objectives

• 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).

Scenarios

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

1. Publishing Coordinator synchronizes with repository
2. Publishing Coordinator edits necessary artefacts
3. Publishing Coordinator commits updated artefact to repository (here, we need a return notification to the committee. Ideally it should include a "list" (manifest?) For those items that publishing has changed. The challenge will arise in the circumstance where the original manifest included artifacts 12 and 3 (see table above) at release 123, the committee has proceeded to make local alterations at release 124, and publishing changes artifact 1 at release 125. At this point, there is a "garbled" manifest, as the correct release for artifact 1 is 125, where is the correct release for artifacts 2 and 3 are 123.

Glossary

Common version control system terms used.

Branch – also known as fork. Create a set of files that will diverge from the main trunk.

Check out – retrieve a set of files from the version control repository, does not imply 'locking' the files. Can be performed against a the main trunk, a branch or a tag

Commit – save a set of file changes in the version control system.

Lock – mark a file such that only the lock owner can update the file.

Sandbox -

Tag – associate a label with a consistent set of files. Often used to identify the files used to create a release.

Trunk – also known as Main Trunk. The main line of descent against which changes are applied.