Difference between revisions of "VPP/CommitterTasks/CutRelease"
From fd.io
< VPP
Dwallacelf (Talk | contribs) (→helpdesk email template) |
Dwallacelf (Talk | contribs) (→Instructions for vpp release manager) |
||
| Line 2: | Line 2: | ||
= Instructions for vpp release manager = | = Instructions for vpp release manager = | ||
| + | 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 | ||
== Prerequisites == | == Prerequisites == | ||
| − | + | 1. Update Wiki - Edit the following wiki pages and add/revise references for new release | |
[[VPP|VPP main page]] | [[VPP|VPP main page]] | ||
[[VPP/Installing VPP binaries from packages|Installing VPP binaries from packages]] | [[VPP/Installing VPP binaries from packages|Installing VPP binaries from packages]] | ||
| − | + | ||
| − | + | 2. Review docs.fd.io for formatting and release content | |
| − | + | ||
| − | + | 3. Update .../vpp/extras/scripts/list_api_changes.py with current release rc0 tag (if necessary) | |
| − | + | ||
| + | 4. Update Release Notes | ||
| + | :a. Edit .../vpp/RELEASE.md and add section for the current release | ||
| + | :b. 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 | git rev-list <release rc0 tag>..HEAD | wc -l | ||
| − | + | :c. Add Features section from the Release Plan & git log (Hint: gitk is your friend, jira not so much) | |
| − | + | :d. [[VPP/CommitterTasks/Compare_API_Changes|Add list of API changes generated using VPP]] | |
| − | + | :e. Add list of patches that changed api files by running the updated list_api_changes.py script | |
| + | |||
| + | 5. Submit release note patch (e.g. "18.01 Release Notes") | ||
| + | |||
| + | 6. Send email to vpp-dev@lists.fd.io asking for feedback on the release notes. | ||
| + | |||
| + | 7. Merge Release Note patch (which should be the patch where the release label is created). | ||
| + | |||
| + | 8. Verify that all merge jobs (including docs) have completed successfully. | ||
== Recipe to Generate the 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 nexus does not allow overwriting artifacts that already exist. If this does happen, then you need to open a helpdesk ticket [mailto:helpdesk@fd.io helpdesk@fd.io] asking for all of the nexus release artifacts to be purged. You may also have to get Ed Warnicke to clean out the release artifacts on packagecloud.io. You can also encounter this issue if the "remerge" jobs fail (keep your fingers crossed ;) | |
| − | + | ||
| − | + | 1. Lay tag for “v18.01” on patch that is “last patch in series" (see [[VPP/Pushing_and_Testing_a_Tag| Pushing and Testing a Tag]] but note '''NO -rc<#>''' suffix!!!) | |
| − | + | ||
| − | + | 2. “remerge” patch on that commit - so it creates various artifacts. | |
| − | + | :* Do remerge as per this [https://www.dropbox.com/s/3xs09a9lnliv1za/Screenshot%202016-09-07%2009.25.56.png?dl=0 picture] | |
| − | + | ||
| − | + | 3. Once remerge jobs have successfully completed open case with LF staff to move artifacts to release repo | |
| − | + | :* email [mailto:helpdesk@fd.io helpdesk@fd.io] using the email 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 (ie Centos7.2, Ubuntu Xenial) - use instructions for [[VPP/Installing_VPP_binaries_from_packages| here]] to install 'release' packages and make sure you get a runnable version for ${release number} using release artifacts | ||
| + | :a. Install binary packages and verify VPP starts on supported VMs without any prior VPP installed | ||
| + | :b. Repeat above but upgrading from prior release of VPP to new release | ||
| + | |||
| + | 6. Contact [mailto:csit-dev@lists.fd.io csit-dev] to ask how they want to test the new artifacts. | ||
== helpdesk email template == | == helpdesk email template == | ||
Revision as of 05:10, 25 January 2018
Contents
Instructions for vpp release manager
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
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. Review docs.fd.io for formatting and release content
3. Update .../vpp/extras/scripts/list_api_changes.py with current release rc0 tag (if necessary)
4. Update Release Notes
- a. Edit .../vpp/RELEASE.md and add section for the current release
- b. 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
- c. Add Features section from the Release Plan & git log (Hint: gitk is your friend, jira not so much)
- d. Add list of API changes generated using VPP
- e. Add list of patches that changed api files by running the updated list_api_changes.py script
5. Submit release note patch (e.g. "18.01 Release Notes")
6. Send email to vpp-dev@lists.fd.io asking for feedback on the release notes.
7. Merge Release Note patch (which should be the patch where the release label is created).
8. Verify that all merge jobs (including docs) have completed successfully.
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 nexus does not allow overwriting artifacts that already exist. If this does happen, then you need to open a helpdesk ticket helpdesk@fd.io asking for all of the nexus release artifacts to be purged. You may also have to get Ed Warnicke to clean out the release artifacts on packagecloud.io. You can also encounter this issue if the "remerge" jobs fail (keep your fingers crossed ;)
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!!!)
2. “remerge” patch on that commit - so it creates various artifacts.
- Do remerge as per this picture
3. 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 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 (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
- a. Install binary packages and verify VPP starts on supported VMs without any prior VPP installed
- b. Repeat above but upgrading from prior release of VPP to new release
6. 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
where '*' is the following directories: vpp, vpp-api-java, vpp-api-lua, vpp-api-python, vpp-devel, vpp-lib, vpp-plugins
DO NOT COPY: vpp-dpdk-devel, if this directory exists, please remove it from the repository
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 without '.'}.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
where '*' is the following directories: vpp, vpp-api-java, vpp-api-lua, vpp-api-python, vpp-dev, vpp-dbg, vpp-lib, vpp-plugins
DO NOT COPY: vpp-dpdk-dev, vpp-dpdk-dkms, if these directories exist, please remove them from the repository.
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.
