VPP/CommitterTasks/CutRelease
From fd.io
Contents
Instructions for vpp release manager
Prerequisites
- Update Wiki - Edit the following wiki pages and add/revise references for new release
VPP main page Installing VPP binaries from packages
- Review docs.fd.io for formatting and release content
- Update .../vpp/extras/scripts/list_api_changes.py with current release rc0 tag (if necessary)
- Update Release Notes
- Edit .../vpp/RELEASE.md and add section for the current release
- Add number of commits by running the following command on the throttle branch (e.g. 18.01 <release rc0 tag> == v18.01-rc0)
git rev-list <release rc0 tag>..HEAD | wc -l
- Add Features section from the Release Plan & git log (Hint: gitk is your friend, jira not so much)
- Add list of API changes generated using VPP
- Add list of patches that changed api files by running the updated list_api_changes.py script
Recipe to Generate the Release
- It is strongly recommended you do this a day or two prior to release if you are relatively sure all needed code for the release is in
- Lay tag for “v16.09” on patch that is “last patch in series" (see Pushing and Testing a Tag but note NO -rc<#> suffix!!!)
- “remerge” patch on that commit - so it creates various artifacts.
- Do remerge as per this picture
- Once remerge jobs have successfully completed open case with LF staff to move artifacts to release repo
- email helpdesk@fd.io using the email template below, substituting ${release number} with the release number (like 17.01) and ${release number without '.'} with the release number without '.' (like 1701).
- Wait for LF infra staff to indicate they have completed the case
- Test install behaviour on currently supported platforms (ie Centos7.2, Ubuntu Xenial) - use instructions for here to install 'release' packages and make sure you get a runnable version for ${release number} using release artifacts
- Install binary packages and verify VPP starts on supported VMs without any prior VPP installed
- Repeat above but upgrading from prior release of VPP to new release
- Contact csit-dev to ask how they want to test the new artifacts.
helpdesk email template
Subject: Publish vpp release artifacts vpp has completed release ${release number}. Please copy: https://nexus.fd.io/content/repositories/fd.io.stable.${release number without '.'}.centos7/io/fd/vpp/*/${release number}-release.x86_64/*.rpm to https://nexus.fd.io/content/repositories/fd.io.centos7/io/fd/vpp/*/${release number}-release.x86_64/*.rpm Please note: the groupId will be io.fd.vpp, the maven version will be ${release_number}-release.x86_64, the artifactId will be the '*' between io/fd/vpp/ and ${release_number}-release.x86_64 Please copy: https://nexus.fd.io/content/repositories/fd.io.stable.${release number}.ubuntu.xenial.main/io/fd/vpp/*/${release number}_amd64/*.deb to https://nexus.fd.io/content/repositories/fd.io.ubuntu.xenial.main/io/fd/vpp/*/${release number}_amd64/*.deb Please note: the groupId will be io.fd.vpp, the maven version will be ${release_number}_amd64, the artifactId will be the '*' between io/fd/vpp/ and ${release number}_amd64 Please copy https://nexus.fd.io/content/repositories/fd.io.snapshot/io/fd/vpp/*/${release number}-SNAPSHOT/*.jar where you select the jar file with the highest build number to https://nexus.fd.io/content/repositories/fd.io.release/io/fd/vpp/*/${release number}/*.jar Please note: the groupId will be io.fd.vpp, the maven version will be ${release_number}, the artifactId will be the '*' between io/fd/vpp/ and ${release number} When performing all of these copies, please make sure to *not* copy the .pom files.