...
Each phase of the release is executed by calling getReleaseData.sh to update the status of the release phase followed by releasePhase.sh to actually perform the release. Note that it is safe to run getReleaseData.sh multiple times in a single release. This may be necessary if, for example, the merge job for a release commit is slow to run causing a phase to complete slowly. Always keep an eye on the output of getReleaseData.sh to verify that the release is proceeding correctly.
Note |
---|
If a repository is released, then you must also release all repositories that depend on it. |
Warning |
---|
With care an expert can It is usually easier to start from Phase 1 and proceed from there. However, with care, it is possible to start from an intermediate phase if repositories early in the release process such as policy/common or policy/models are not being released. If a repository is released, then you must also release all repositories that depend on itTo do this, the expert can carefully edit your local copy of the releasePhase.sh script and comment out the parts of each release phase that the expert does not want to execute. For example, if the expert wants to start from Phase 8 below (use the existing versions of policy/parent, policy/common, policy/docker, and policy/models), the expert can comment out the operation to update the policy/models snapshots and safely start from Phase 8. |
Running a Release
In each phase run getReleaseData.sh followed by releasePhase.sh.
...