VPP CommitterTasks CutPointRelease

VPP Point Release Tasklist

1. Announce intention to create a point release at 1 or 2 weeks prior at VPP Bi-Weekly meeting and via email.

2. Update Release Notes

   a. On the release throttle branch (e.g. stable/1801), edit .../vpp/RELEASE.md and add section for the point release

   [Bug fix release note](https://docs.fd.io/vpp/18.01/release_notes_18011.html)
   
   [1801.1 release notes patch](https://gerrit.fd.io/r/#/c/10416/1/RELEASE.md)
   

   b. From workspace root, build doxygen output

       make bootstrap-doxygen doxygen
   

   c. Check documentation output by opening the document index file in a browser:

   file:///<path to workspace root>/build-root/docs/html/index.html
   

   d. Clean up any formatting issues found.

   e. Submit patch.

   f. After patch is merged, cherry-pick it to master. If a newer release branch exists, merge the patch into the release branch, then cherry-pick it to master.

3. Send an email reminder to the VPP Committers to NOT MERGE ANY PATCHES onto the stable branch until after the completion of the point release has been announced on email.

4. Follow the recipe to generate the release using the point release number (e.g. s/18.01/18.01.1/g).

5. Update the link to the VPP documentation on the VPP Wiki main page (e.g. s/18.01/18.01.1/g)

   Edit VPP Documents Section

Post Release Tasks

1. Watch the release branch for the first post point release patch. A new .<#>-rc0 tag is required to ensure that the latest build artifacts get downloaded from packagecloud.io when Installing VPP binaries from packages

2. Lay the tag for “v18.01.2-rc0” on first patch after the release (see Pushing and Testing a Tag). If there has been more than one patch merged onto the release branch, then add the git id of the first patch after release to the end of the "git tag" command when creating the tag.

3. Remerge the patch at HEAD of the release branch to generate the correct artifacts in the packagecloud.io repository.