VPP CommitterTasks CutRelease

Contents

• 1 Instructions for vpp release manager
• 2 Prerequisites
• 3 Recipe to Generate the Release
• 4 helpdesk template

Instructions for vpp release manager

It is strongly recommended you do the prerequisites the week prior to the FR Milestone and start the release process a day or two prior to release.

Prerequisites

1. Update Wiki - Edit the following wiki pages and add/revise references for new release

   VPP main page

   Installing VPP binaries from packages

2. Update release notes

   a. Edit .../vpp/RELEASE.md and add section for the current release

   b. On the release throttle branch (e.g. stable/1801), copy the auto-generated release notes to docs/aboutvpp/releasenotes/v<YY.MM>.rst and add the release note file to the release notes index file docs/aboutvpp/releasenotes/index.rst.

   c. Make any additional edits to the release notes RST file (as necessary).

3. Submit release notes patch (e.g. "18.01 Release Notes")

4. Send email to email asking for feedback on the release notes patch.

5. Merge release notes patch (which should be the patch where the release label is created).

6. Verify that all merge jobs (including docs) have completed successfully.

7. Cherry-pick release notes patch to master.

8. Review patches to the previous stable/XXXX release branch to ensure that all bug fixes in the previous release are contained in the new release.

Recipe to Generate the Release

WARNING: If you push the release tag before the merge jobs have completed from the release note patch, then the merge jobs will fail when you do the "remerge" step below because packagecloud.io does not allow overwriting artifacts that already exist.

1. Lay tag for “v18.01” on patch that is “last patch in series" (see Pushing and Testing a Tag but note NO -rc<#> suffix!!!)

1a. IMPORTANT: verify in https://git.fd.io/vpp/ that the tag has been propagated and is visible. It sometimes takes a while. If the correct tag is not there at the time of the merge job start, the artifact labelling will be wrong.

2. “remerge” patch on that commit - so it creates various artifacts.

3. Once remerge jobs have successfully completed open case with LF staff to move artifacts to release repo

   • Open a helpdesk ticket using the template below, substituting ${release number} with the release number (like 18.01) and ${release number without '.'} with the release number without '.' (like 1801).

4. Wait for LF infra staff to indicate they have completed the case

5. Test install behaviour on currently supported platforms - use instructions for here to install 'release' packages and make sure you get a runnable version for ${release number} using release artifacts

   a. Review the packages on PackageCloud.io (change release number in the search bar as necessary):

   VPP 19.04.1 Ubuntu 16.04 (xenial) Release packages

   VPP 19.04.1 Ubuntu 18.04 (bionic) X86_64 Release packages

   VPP 19.04.1 Ubuntu 18.04 (bionic) ARM64 Release packages

   VPP External Dependencies packages

   b. Install binary packages and verify VPP starts on supported VMs without any prior VPP installed

6. Declare Victory!

• Email vpp-dev and csit-dev to announce the availability of the release artifacts on nexus.fd.io.

helpdesk template

Subject: Please publish VPP ${release number} Release Artifacts

Dear [email protected],

The VPP artifacts for release ${release number} are now available on packagecloud.io and are ready to be copied into the release directories.

Please let me know when they have been published so I can test the VPP ${release number} packages from packagecloud.io/fdio/release.

Thanks,
<Your Friendly VPP Release Manager>