17.7 Tagging the Phase 0 Baseline [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 17.7 Tagging the Phase 0 Baseline ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:17-git-and-review-workflow:start | Return to Git and Review Workflow ]]

The team should tag important Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]] in Git so that developers, testers, reviewers, and demonstration participants can reproduce a known state of the Repository.

A tag may identify:

  - Initial Repository Baseline.
  - Accepted Phase 0 tool Baseline.
  - Accepted IDL/type-generation Baseline.
  - First successful Node-network run.
  - Acceptance candidate.
  - Demonstration candidate.
  - Accepted Phase 0 demonstration Baseline.

Tag names should be clear and stable. Representative tag names include:

  * ''phase0-repository-baseline-001''
  * ''phase0-type-generation-baseline-001''
  * ''phase0-node-network-run-001''
  * ''phase0-demo-candidate-001''
  * ''phase0-accepted-baseline-001''

A tag should point to a Repository state that the team can explain. Before tagging a Baseline, the team should confirm that relevant documentation, checklist instances, generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]] policy, scripts, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]], tests, logs, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] align with the tagged state.

The team should avoid moving or reusing tags once other people rely on them. If the team needs a corrected Baseline, it should create a new tag rather than rewriting the meaning of an existing one.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>