Latest revision as of 16:57, 2 August 2019

Describe the steps in creating a StarlingX Release

Release Activity

[Note: StarlingX has not used milestone branches since the 1.0 release (AKA 2018.10). ]

Finalize any outstanding changes to master stx-manifest/default.xml, particularly for the starlingx and stx-staging remotes as those are used to create the list of repos to branch and tag.
Create the branches and tag them by running stx-tools/release/branch-stx.sh. Set SERIES to the proper value if the current year/month is not correct:
```
SERIES=2018.07 stx-tools/release/branch-stx.sh
```
Create the branch manifest in stx-manifest/default.xml
Review and approve the .gitreview updates in the new branch

Make a cleanup pass though release notes and add missing
Finalize any outstanding changes to master stx-manifest/default.xml, particularly for the starlingx and stx-staging remotes as those are used to create the list of repos to branch and tag.
Create the branches and tag them by running stx-tools/release/branch-stx.sh. Set SERIES, BRANCH and TAG to the proper values and use the manifest to retrieve the repo list:
- SERIES=stx.X.0
- BRANCH=r/stx.X.0
- TAG=vX.0.0.rc0
- -m <path>/default.xml

SERIES=stx.2.0 BRANCH=r/stx.2.0 TAG=v2.0.0.rc0 ../tools/release/branch-stx.sh -m ../manifest/default.xml

SERIES=stx.2.0 BRANCH=r/stx.2.0 TAG=v2.0.0.rc0 ../tools/release/branch-stx.sh https://opendev.org/starlingx/manifest.git

Make any branch-specific updates to the manifest and create a new review if necessary
Review and approve the .gitreview updates in the new branch
Look for UPPER_CONSTRAINTS_FILE values to update for stable branches (there may not be any as this is an OpenStack-ism that we would change when rebasing OpenStack projects)
Verify release notes appear correctly and make adjustments

Found in stx-tools/release, performs the following steps for each repo listed on the command line:

if -m <manifest> is included on the command line add the repo list extracted from stx-manifest/default.xml for the starlingx and stx-staging remotes using getrepo.sh (also in stx-tools/release)
for each repo:
- clone repo
- create the new branch
- tag branch if TAG is set
- for gerrit (starlingx) repos:
  - push to gerrit
  - update .gitreview
- for Github repos (stx-staging):
  - push to github

@@ Line 15: / Line 15: @@
 * Make a cleanup pass though release notes and add missing
 * Finalize any outstanding changes to master stx-manifest/default.xml, particularly for the starlingx and stx-staging remotes as those are used to create the list of repos to branch and tag.
-* Create the branches and tag them by running stx-tools/release/branch-stx.sh.  Set SERIES, BRANCH and TAG to the proper values:
+* Create the branches and tag them by running stx-tools/release/branch-stx.sh.  Set SERIES, BRANCH and TAG to the proper values and use the manifest to retrieve the repo list:
 ** SERIES=stx.X.0
 ** BRANCH=r/stx.X.0
 ** TAG=vX.0.0.rc0
-* Create the branch manifest in stx-manifest/default.xml
+** -m <path>/default.xml
+<pre>SERIES=stx.2.0 BRANCH=r/stx.2.0 TAG=v2.0.0.rc0 ../tools/release/branch-stx.sh -m ../manifest/default.xml</pre>
+* Create the branch manifest in starlingx/manifest/default.xml
+<pre>SERIES=stx.2.0 BRANCH=r/stx.2.0 TAG=v2.0.0.rc0 ../tools/release/branch-stx.sh https://opendev.org/starlingx/manifest.git</pre>
+* Make any branch-specific updates to the manifest and create a new review if necessary
 * Review and approve the .gitreview updates in the new branch
 * Look for UPPER_CONSTRAINTS_FILE values to update for stable branches (there may not be any as this is an OpenStack-ism that we would change when rebasing OpenStack projects)