Difference between revisions of "VPP/CommitterTasks/CutRelease"

From fd.io
< VPP
Jump to: navigation, search
(→‎Instructions for vpp release manager)
(→‎Recipe to Generate the Release)
 
(26 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
__TOC__
 
__TOC__
  
−
= 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
+
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 ==
 
== Prerequisites ==
 
1. Update Wiki - Edit the following wiki pages and add/revise references for new release
 
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
+
2. Review docs.fd.io
 +
:a. On the release throttle branch (e.g. stable/1801), add release specific links to .../vpp/doxygen/test_framework_doc.md
 +
:b. <b>pre-22.02</b> From workspace root, build doxygen output
 +
::<pre>make bootstrap-doxygen doxygen</pre>
 +
:b. <b>post-22.02</b> From workspace root, build docs
 +
::<pre>make docs</pre>
 +
: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.
  
 
3. Update .../vpp/extras/scripts/list_api_changes.py with current release rc0 tag (if necessary)
 
3. Update .../vpp/extras/scripts/list_api_changes.py with current release rc0 tag (if necessary)
  
−
4. Update Release Notes
+
4. Update release notes
 
:a. Edit .../vpp/RELEASE.md and add section for the current release
 
: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)
 
: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
+
::<pre>git rev-list <release rc0 tag>..HEAD | wc -l</pre>
 
:c. Add Features section from the Release Plan & git log (Hint: gitk is your friend, jira not so much)
 
: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]]
 
: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
 
: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")
+
5. Submit release notes patch (e.g. "18.01 Release Notes")
  
−
6. Send email to vpp-dev@lists.fd.io asking for feedback on the release notes.
+
6. Send email to vpp-dev@lists.fd.io asking for feedback on the release notes patch.
  
−
7. Merge Release Note patch (which should be the patch where the release label is created).
+
7. Merge release notes patch (which should be the patch where the release label is created).
  
 
8. Verify that all merge jobs (including docs) have completed successfully.
 
8. Verify that all merge jobs (including docs) have completed successfully.
  
−
== Recipe to Generate the Release ==
+
9. Cherry-pick release notes patch to master.
−
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!!!)
+
10. 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.
  
−
2. “remerge” patch on that commit - so it creates various artifacts.
+
== Recipe to Generate the Release ==
−
:* Do remerge as per this [https://www.dropbox.com/s/3xs09a9lnliv1za/Screenshot%202016-09-07%2009.25.56.png?dl=0 picture]
+
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 [https://support.linuxfoundation.org helpdesk ticket] asking for all of the nexus release artifacts to be purged.  You can also encounter this issue if the "remerge" jobs fail (keep your fingers crossed ;)
  
−
3. Once remerge jobs have successfully completed open case with LF staff to move artifacts to release repo
+
1. Send an email reminder to the VPP Committers to NOT MERGE ANY PATCHES onto the stable branch until after the completion of the release has been announced on vpp-dev@lists.fd.io.
−
:* 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
+
2. 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!!!)
  
−
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
+
2a. 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.
−
: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.
+
3. “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]
  
−
== helpdesk email template ==
+
4. Once remerge jobs have successfully completed open case with LF staff to move artifacts to release repo
−
<pre>
+
:* Open a [https://support.linuxfoundation.org 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).
−
Subject: Publish vpp release artifacts
+
  
−
vpp has completed release ${release number}.
+
5. Wait for LF infra staff to indicate they have completed the case
  
 +
6. 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. Review the packages on PackageCloud.io (change release number in the search bar as necessary):
 +
:: [https://packagecloud.io/app/fdio/release/search?q=19.04.1-release&filter=all&dist=el%2F7 VPP 19.04.1 Centos7 Release packages ]
 +
:: [https://packagecloud.io/app/fdio/release/search?q=19.04.1-release&filter=all&filter=all&dist=ubuntu%2Fxenial VPP 19.04.1 Ubuntu 16.04 (xenial) Release packages ]
 +
:: [https://packagecloud.io/app/fdio/release/search?q=19.04.1-release_amd&filter=all&filter=all&dist=ubuntu%2Fbionic VPP 19.04.1 Ubuntu 18.04 (bionic) X86_64 Release packages]
 +
:: [https://packagecloud.io/app/fdio/release/search?q=19.04.1-release_arm&filter=all&filter=all&dist=ubuntu%2Fbionic VPP 19.04.1 Ubuntu 18.04 (bionic) ARM64 Release packages]
 +
:: [https://packagecloud.io/app/fdio/release/search?q=vpp-ext-dep&filter=all&filter=all&dist= VPP External Dependencies packages]
 +
:b. Install binary packages and verify VPP starts on supported VMs without any prior VPP installed
  
−
Please copy:
+
7. Release the version in Jira
  
−
https://nexus.fd.io/content/repositories/fd.io.stable.${release number without '.'}.centos7/io/fd/vpp/*/${release number}-release.x86_64/*.rpm
+
VPP committers should have admin access to Jira. From https://jira.fd.io/plugins/servlet/project-config/VPP/summary navigate to ''Releases'' (Or ''Versions'', same thing) and under ''Actions'' for the release, select ''Release''.
  
−
to
+
Tell Jira to move all still-open issues into the next release and set the release date appropriately.
  
−
https://nexus.fd.io/content/repositories/fd.io.centos7/io/fd/vpp/*/${release number}-release.x86_64/*.rpm
+
8. Declare Victory!
 +
:* Email [mailto:vpp-dev@lists.fd.io vpp-dev] and [mailto:csit-dev@lists.fd.io csit-dev] to announce the availability of the release artifacts on nexus.fd.io.
  
−
where '*' is the following directories: vpp, vpp-api-java, vpp-api-lua, vpp-api-python, vpp-devel, vpp-lib, vpp-plugins
+
== helpdesk template ==
−
DO NOT COPY: vpp-dpdk-devel, if this directory exists, please remove it from the repository
+
<pre>
 +
Subject: Please publish VPP ${release number} Release Artifacts
  
−
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
+
Dear Helpdesk@fd.io,
  
 +
The VPP artifacts for release ${release number} are now available on packagecloud.io and are ready to be copied into the release directories.
  
−
Please copy:
+
Please let me know when they have been published so I can test the VPP ${release number} packages from packagecloud.io/fdio/release.
  
−
https://nexus.fd.io/content/repositories/fd.io.stable.${release number without '.'}.ubuntu.xenial.main/io/fd/vpp/*/${release number}_amd64/*.deb
+
Thanks,
 +
<Your Friendly VPP Release Manager>
 +
</pre>
  
−
to
+
== Post Release Tasks ==
  
−
https://nexus.fd.io/content/repositories/fd.io.ubuntu.xenial.main/io/fd/vpp/*/${release number}_amd64/*.deb
+
1. Rebuild the docs
 +
make docs-venv docs
  
−
where '*' is the following directories: vpp, vpp-api-java, vpp-api-lua, vpp-api-python, vpp-dev, vpp-dbg, vpp-lib, vpp-plugins
+
2. Submit the patch containing the updated docs about release version file .../docs/about.rst
−
DO NOT COPY: vpp-dpdk-dev, vpp-dpdk-dkms, if these directories exist, please remove them from the repository.
+
* For example, [https://gerrit.fd.io/r/c/vpp/+/23047 VPP 19.04.3 docs build info]
  
−
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
+
3. Create the tag for the next maintenance release “v19.04.4-rc0” on the patch (see [[VPP/Pushing_and_Testing_a_Tag| Pushing and Testing a Tag]]).
 +
This tag is required to ensure that the latest artifacts pushed to packagecloud.io/1904 get retrieved when pulling from the repo using apt or yum.
  
−
 
+
4. Merge the patch [Verified +1, Code Review +2]
−
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.
+
−
</pre>
+

Latest revision as of 15:58, 30 October 2024

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. Review docs.fd.io

a. On the release throttle branch (e.g. stable/1801), add release specific links to .../vpp/doxygen/test_framework_doc.md
b. pre-22.02 From workspace root, build doxygen output 
make bootstrap-doxygen doxygen
b. post-22.02 From workspace root, build docs 
make docs
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.

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 notes patch (e.g. "18.01 Release Notes")

6. Send email to vpp-dev@lists.fd.io asking for feedback on the release notes patch.

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

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

9. Cherry-pick release notes patch to master.

10. 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 nexus does not allow overwriting artifacts that already exist. If this does happen, then you need to open a helpdesk ticket asking for all of the nexus release artifacts to be purged. You can also encounter this issue if the "remerge" jobs fail (keep your fingers crossed ;)

1. Send an email reminder to the VPP Committers to NOT MERGE ANY PATCHES onto the stable branch until after the completion of the release has been announced on vpp-dev@lists.fd.io.

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

2a. 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.

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

4. 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).

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

6. 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. Review the packages on PackageCloud.io (change release number in the search bar as necessary):
VPP 19.04.1 Centos7 Release packages
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

7. Release the version in Jira

VPP committers should have admin access to Jira. From https://jira.fd.io/plugins/servlet/project-config/VPP/summary navigate to Releases (Or Versions, same thing) and under Actions for the release, select Release.

Tell Jira to move all still-open issues into the next release and set the release date appropriately.

8. 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 Helpdesk@fd.io,

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>

Post Release Tasks

1. Rebuild the docs 

make docs-venv docs

2. Submit the patch containing the updated docs about release version file .../docs/about.rst

3. Create the tag for the next maintenance release “v19.04.4-rc0” on the patch (see Pushing and Testing a Tag). This tag is required to ensure that the latest artifacts pushed to packagecloud.io/1904 get retrieved when pulling from the repo using apt or yum.

4. Merge the patch [Verified +1, Code Review +2]

Retrieved from "https://wiki.fd.io/index.php?title=VPP/CommitterTasks/CutRelease&oldid=12757"