You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by gi...@apache.org on 2020/08/07 12:02:21 UTC
[beam] branch asf-site updated: Publishing website 2020/08/07
12:02:08 at commit fed3763
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 5f9466f Publishing website 2020/08/07 12:02:08 at commit fed3763
5f9466f is described below
commit 5f9466f65534feac745ee6c159726cc2acfee902
Author: jenkins <us...@infra.apache.org>
AuthorDate: Fri Aug 7 12:02:09 2020 +0000
Publishing website 2020/08/07 12:02:08 at commit fed3763
---
website/generated-content/contribute/index.xml | 64 +++++++++++++++-------
.../contribute/release-guide/index.html | 22 +++++---
website/generated-content/sitemap.xml | 2 +-
3 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/website/generated-content/contribute/index.xml b/website/generated-content/contribute/index.xml
index a0f5813..48e3c4d 100644
--- a/website/generated-content/contribute/index.xml
+++ b/website/generated-content/contribute/index.xml
@@ -216,11 +216,14 @@ limitations under the License.
<li><a href="#introduction">Introduction</a>
<ul>
<li><a href="#overview">Overview</a></li>
-<li><a href="#decide-to-release">Decide to release</a></li>
+</ul>
+</li>
+<li><a href="#1-decide-to-release">1. Decide to release</a>
+<ul>
<li><a href="#checklist-to-proceed-to-the-next-step">Checklist to proceed to the next step</a></li>
</ul>
</li>
-<li><a href="#1-prepare-for-the-release">1. Prepare for the release</a>
+<li><a href="#2-prepare-for-the-release">2. Prepare for the release</a>
<ul>
<li><a href="#accounts">Accounts</a></li>
<li><a href="#one-time-setup-instructions">One-time setup instructions</a>
@@ -236,7 +239,8 @@ limitations under the License.
<li><a href="#create-a-new-version-in-jira">Create a new version in JIRA</a></li>
</ul>
</li>
-<li><a href="#2-create-a-release-branch-in-apachebeam-repository">2. Create a release branch in apache/beam repository</a>
+<li><a href="#3-investigate-performance-regressions">3. Investigate performance regressions</a></li>
+<li><a href="#4-create-a-release-branch-in-apachebeam-repository">4. Create a release branch in apache/beam repository</a>
<ul>
<li>
<ul>
@@ -252,7 +256,7 @@ limitations under the License.
</li>
</ul>
</li>
-<li><a href="#3-verify-release-branch">3. Verify release branch</a>
+<li><a href="#5-verify-release-branch">5. Verify release branch</a>
<ul>
<li>
<ul>
@@ -260,16 +264,17 @@ limitations under the License.
<li><a href="#verify-the-build-succeeds">Verify the build succeeds</a></li>
<li><a href="#alternative-run-release-build-manually-locally">(Alternative) Run release build manually (locally)</a></li>
<li><a href="#create-release-blocking-issues-in-jira">Create release-blocking issues in JIRA</a></li>
+<li><a href="#inform-the-mailing-list">Inform the mailing list</a></li>
</ul>
</li>
</ul>
</li>
-<li><a href="#4-triage-release-blocking-issues-in-jira">4. Triage release-blocking issues in JIRA</a>
+<li><a href="#6-triage-release-blocking-issues-in-jira">6. Triage release-blocking issues in JIRA</a>
<ul>
<li><a href="#review-cherry-picks">Review cherry-picks</a></li>
</ul>
</li>
-<li><a href="#5-build-a-release-candidate">5. Build a release candidate</a>
+<li><a href="#7-build-a-release-candidate">7. Build a release candidate</a>
<ul>
<li><a href="#checklist-before-proceeding">Checklist before proceeding</a></li>
<li><a href="#run-build_release_candidatesh-to-create-a-release-candidate">Run build_release_candidate.sh to create a release candidate</a>
@@ -279,7 +284,7 @@ limitations under the License.
</li>
</ul>
</li>
-<li><a href="#6-prepare-documents">6. Prepare documents</a>
+<li><a href="#8-prepare-documents">8. Prepare documents</a>
<ul>
<li><a href="#update-and-verify-javadoc">Update and Verify Javadoc</a></li>
<li><a href="#build-the-pydoc-api-reference">Build the Pydoc API reference</a></li>
@@ -291,7 +296,7 @@ limitations under the License.
</li>
</ul>
</li>
-<li><a href="#7-vote-and-validate-release-candidate">7. Vote and validate release candidate</a>
+<li><a href="#9-vote-and-validate-release-candidate">9. Vote and validate release candidate</a>
<ul>
<li><a href="#run-validation-tests">Run validation tests</a>
<ul>
@@ -303,7 +308,7 @@ limitations under the License.
<li><a href="#checklist-to-proceed-to-the-next-step-2">Checklist to proceed to the next step</a></li>
</ul>
</li>
-<li><a href="#8-finalize-the-release">8. Finalize the release</a>
+<li><a href="#10-finalize-the-release">10. Finalize the release</a>
<ul>
<li><a href="#deploy-artifacts-to-maven-central-repository">Deploy artifacts to Maven Central Repository</a></li>
<li><a href="#deploy-python-artifacts-to-pypi">Deploy Python artifacts to PyPI</a></li>
@@ -320,7 +325,7 @@ limitations under the License.
<li><a href="#checklist-to-proceed-to-the-next-step-3">Checklist to proceed to the next step</a></li>
</ul>
</li>
-<li><a href="#9-promote-the-release">9. Promote the release</a>
+<li><a href="#11-promote-the-release">11. Promote the release</a>
<ul>
<li><a href="#apache-mailing-lists">Apache mailing lists</a></li>
<li><a href="#social-media">Social media</a></li>
@@ -341,6 +346,9 @@ limitations under the License.
<ol>
<li>Decide to release</li>
<li>Prepare for the release</li>
+<li>Investigate performance regressions</li>
+<li>Create a release branch</li>
+<li>Verify release branch</li>
<li>Build a release candidate</li>
<li>Vote on the release candidate</li>
<li>During vote process, run validation tests</li>
@@ -348,7 +356,7 @@ limitations under the License.
<li>Finalize the release</li>
<li>Promote the release</li>
</ol>
-<h3 id="decide-to-release">Decide to release</h3>
+<h2 id="1-decide-to-release">1. Decide to release</h2>
<p>Deciding to release and selecting a Release Manager is the first step of the release process. This is a consensus-based decision of the entire community.</p>
<p>Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the Release Manager (including themselves). There’s no formal process, no vote requirements, and no timing requirements. Any objections should be resolved by consensus before starting the release.</p>
<p>In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers allows enough people to build expertise in this area and improve processes over time, without Release Managers needing to re-learn the processes for each release. That said, if you are a committer interested in serving the community in this way, please reach out to the community on the dev@ mailing list.</p>
@@ -358,7 +366,7 @@ limitations under the License.
<li>Community selects a Release Manager</li>
</ol>
<hr>
-<h2 id="1-prepare-for-the-release">1. Prepare for the release</h2>
+<h2 id="2-prepare-for-the-release">2. Prepare for the release</h2>
<p>Before your first release, you should perform one-time configuration steps. This will set up your security keys for signing the release and access to various release repositories.</p>
<p>To prepare for each release, you should audit the project status in the JIRA issue tracker, and do necessary bookkeeping. Finally, you should create a release branch from which individual release candidates will be built.</p>
<p><strong>NOTE</strong>: If you are using <a href="https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/">GitHub two-factor authentication</a> and haven&rsquo;t configure HTTPS access,
@@ -530,7 +538,19 @@ Release Manager
<li>At the end of the release, go to the same page and mark the recently released version as released. Use the <code>...</code> menu and choose <code>Release</code>.</li>
</ol>
<hr>
-<h2 id="2-create-a-release-branch-in-apachebeam-repository">2. Create a release branch in apache/beam repository</h2>
+<h2 id="3-investigate-performance-regressions">3. Investigate performance regressions</h2>
+<p>Check the Beam load tests for possible performance regressions. Measurements are available on <a href="http://metrics.beam.apache.org">metrics.beam.apache.org</a>.</p>
+<p>All Runners which publish data should be checked for the following, in both <em>batch</em> and <em>streaming</em> mode:</p>
+<ul>
+<li><a href="http://metrics.beam.apache.org/d/MOi-kf3Zk/pardo-load-tests">ParDo</a> and <a href="http://metrics.beam.apache.org/d/UYZ-oJ3Zk/gbk-load-test">GBK</a>: Runtime, latency, checkpoint duration</li>
+<li><a href="http://metrics.beam.apache.org/d/ahuaA_zGz/nexmark">Nexmark</a>: Query runtime for all queries</li>
+<li><a href="http://metrics.beam.apache.org/d/bnlHKP3Wz/java-io-it-tests-dataflow">IO</a>: Runtime</li>
+</ul>
+<p>If regressions are found, the release branch can still be created, but the regressions should be investigated and fixed as part of the release process.
+The role of the release manager is to file JIRA issues for each regression with the &lsquo;Fix Version&rsquo; set to the to-be-released version. The release manager
+oversees these just like any other JIRA issue marked with the &lsquo;Fix Version&rsquo; of the release.</p>
+<p>The mailing list should be informed to allow fixing the regressions in the course of the release.</p>
+<h2 id="4-create-a-release-branch-in-apachebeam-repository">4. Create a release branch in apache/beam repository</h2>
<p>Attention: Only committer has permission to create release branch in apache/beam.</p>
<p>Release candidates are built from a release branch. As a final step in preparation for the release, you should create the release branch, push it to the Apache code repository, and update version information on the original branch.</p>
<p>There are 2 ways to cut a release branch: either running automation script(recommended), or running all commands manually.</p>
@@ -662,7 +682,7 @@ so builds will be broken until a new snapshot is available.</p>
<li>Verify that build succeeds.</li>
</ul>
<hr>
-<h2 id="3-verify-release-branch">3. Verify release branch</h2>
+<h2 id="5-verify-release-branch">5. Verify release branch</h2>
<p>After the release branch is cut you need to make sure it builds and has no significant issues that would block the creation of the release candidate.
There are 2 ways to perform this verification, either running automation script(recommended), or running all commands manually.</p>
<p>! Dataflow tests will fail if Dataflow worker container is not created and published by this time. (Should be done by Google)</p>
@@ -781,8 +801,12 @@ to find environment issues this way without having to wait until the full build
<p>Description: Description of failure</p>
</li>
</ul>
+<h4 id="inform-the-mailing-list">Inform the mailing list</h4>
+<p>The <a href="mailto:dev@beam.apache.org">dev@beam.apache.org</a> mailing list should be informed about the release branch being cut. Alongside with this note,
+a list of pending issues and to-be-trigated issues should be included. Afterwards, this list can be refined and updated
+by the release manager and the Beam community.</p>
<hr>
-<h2 id="4-triage-release-blocking-issues-in-jira">4. Triage release-blocking issues in JIRA</h2>
+<h2 id="6-triage-release-blocking-issues-in-jira">6. Triage release-blocking issues in JIRA</h2>
<p>There could be outstanding release-blocking issues, which should be triaged before proceeding to build a release candidate. We track them by assigning a specific <code>Fix version</code> field even before the issue resolved.</p>
<p>The list of release-blocking issues is available at the <a href="https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel">version status page</a>. Triage each unresolved issue with one of the following resolutions:</p>
<p>The release manager should triage what does and does not block a release. An issue should not block the release if the problem exists in the current released version or is a bug in new functionality that does not exist in the current released version. It should be a blocker if the bug is a regression between the currently released version and the release in progress and has no easy workaround.</p>
@@ -820,7 +844,7 @@ Make sure they have blocker JIRAs attached and are OK to get into the release by
<p>It is important to accept major/blocking fixes to isolated issues to make a higher quality release. However, beyond that each cherry pick will increase the time required for the release and add more last minute code to the release branch. Neither late releases nor not fully tested code will provide positive user value.</p>
<p><em>Tip</em>: Another tool in your toolbox is the known issues section of the release blog. Consider adding known issues there for minor issues instead of accepting cherry picks to the release branch.</p>
<hr>
-<h2 id="5-build-a-release-candidate">5. Build a release candidate</h2>
+<h2 id="7-build-a-release-candidate">7. Build a release candidate</h2>
<h3 id="checklist-before-proceeding">Checklist before proceeding</h3>
<ul>
<li>Release Manager’s GPG key is published to <code>dist.apache.org</code>;</li>
@@ -905,7 +929,7 @@ ls -al /opt/apache/beam/third_party_licenses/ | wc -l
</li>
</ol>
<hr>
-<h2 id="6-prepare-documents">6. Prepare documents</h2>
+<h2 id="8-prepare-documents">8. Prepare documents</h2>
<h3 id="update-and-verify-javadoc">Update and Verify Javadoc</h3>
<p>The build with <code>-PisRelease</code> creates the combined Javadoc for the release in <code>sdks/java/javadoc</code>.</p>
<p>The file <code>sdks/java/javadoc/build.gradle</code> contains a list of modules to include
@@ -1014,7 +1038,7 @@ ${CONTRIBUTORS}
<pre><code>docker pull {image_name}
docker pull apache/beam_python3.5_sdk:2.16.0_rc1
</code></pre><hr>
-<h2 id="7-vote-and-validate-release-candidate">7. Vote and validate release candidate</h2>
+<h2 id="9-vote-and-validate-release-candidate">9. Vote and validate release candidate</h2>
<p>Once you have built and individually reviewed the release candidate, please share it for the community-wide review. Please review foundation-wide <a href="http://www.apache.org/foundation/voting.html">voting guidelines</a> for more information.</p>
<p>Start the review-and-vote thread on the dev@ mailing list. Here’s an email template; please adjust as you see fit.</p>
<pre><code>From: Release Manager
@@ -1328,7 +1352,7 @@ mvn compile exec:java -Dexec.mainClass=org.apache.beam.examples.complete.game.in
<li>Community votes to release the proposed candidate, with at least three approving PMC votes</li>
</ol>
<hr>
-<h2 id="8-finalize-the-release">8. Finalize the release</h2>
+<h2 id="10-finalize-the-release">10. Finalize the release</h2>
<p>Once the release candidate has been reviewed and approved by the community, the release should be finalized. This involves the final deployment of the release candidate to the release repositories, merging of the website changes, etc.</p>
<h3 id="deploy-artifacts-to-maven-central-repository">Deploy artifacts to Maven Central Repository</h3>
<p>Use the <a href="https://repository.apache.org/#stagingRepositories">Apache Nexus repository manager</a> to release the staged binary artifacts to the Maven Central repository. In the <code>Staging Repositories</code> section, find the relevant release candidate <code>orgapachebeam-XXX</code> entry and click <code>Release</code>. Drop all other release candidates that are not being released.
@@ -1395,7 +1419,7 @@ git push https://github.com/apache/beam &quot;$VERSION_TAG&quot;
<li>Release version is listed at reporter.apache.org</li>
</ul>
<hr>
-<h2 id="9-promote-the-release">9. Promote the release</h2>
+<h2 id="11-promote-the-release">11. Promote the release</h2>
<p>Once the release has been finalized, the last step of the process is to promote the release within the project and beyond.</p>
<h3 id="apache-mailing-lists">Apache mailing lists</h3>
<p>Announce on the dev@ mailing list that the release has been finished.</p>
diff --git a/website/generated-content/contribute/release-guide/index.html b/website/generated-content/contribute/release-guide/index.html
index 8bc0136..002ffb4 100644
--- a/website/generated-content/contribute/release-guide/index.html
+++ b/website/generated-content/contribute/release-guide/index.html
@@ -1,7 +1,7 @@
<!doctype html><html lang=en class=no-js><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1"><title>Beam Release Guide</title><meta name=description content="Apache Beam is an open source, unified model and set of language-specific SDKs for defining and executing data processing workflows, and also data ingestion and integration flows, supporting Enterprise Integration Patterns (EIPs) and Domain Spe [...]
<span class=sr-only>Toggle navigation</span>
<span class=icon-bar></span><span class=icon-bar></span><span class=icon-bar></span></button>
-<a href=/ class=navbar-brand><img alt=Brand style=height:25px src=/images/beam_logo_navbar.png></a></div><div class="navbar-mask closed"></div><div id=navbar class="navbar-container closed"><ul class="nav navbar-nav"><li><a href=/get-started/beam-overview/>Get Started</a></li><li><a href=/documentation/>Documentation</a></li><li><a href=/documentation/sdks/java/>Languages</a></li><li><a href=/documentation/runners/capability-matrix/>RUNNERS</a></li><li><a href=/roadmap/>Roadmap</a></li>< [...]
+<a href=/ class=navbar-brand><img alt=Brand style=height:25px src=/images/beam_logo_navbar.png></a></div><div class="navbar-mask closed"></div><div id=navbar class="navbar-container closed"><ul class="nav navbar-nav"><li><a href=/get-started/beam-overview/>Get Started</a></li><li><a href=/documentation/>Documentation</a></li><li><a href=/documentation/sdks/java/>Languages</a></li><li><a href=/documentation/runners/capability-matrix/>RUNNERS</a></li><li><a href=/roadmap/>Roadmap</a></li>< [...]
please follow <a href=https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/>the guide</a> to configure command line access.</p><h3 id=accounts>Accounts</h3><p>Please have these credentials ready at hand, you will likely need to enter them multiple times:</p><ul><li>GPG pass phrase (see the next section);</li><li>Apache ID and Password;</li><li>GitHub ID and Password.</li><li>DockerHub ID and Password. (You should be a member of maintainer team; email at [...]
or running all commands manually.</p><h5 id=use-preparation_before_releasesh-to-setup-gpg>Use preparation_before_release.sh to setup GPG</h5><ul><li><p>Script: <a href=https://github.com/apache/beam/blob/master/release/src/main/scripts/preparation_before_release.sh>preparation_before_release.sh</a></p></li><li><p>Usage</p><pre><code>./beam/release/src/main/scripts/preparation_before_release.sh
</code></pre></li><li><p>Tasks included</p><ol><li><p>Help you create a new GPG key if you want.</p></li><li><p>Configure <code>git user.signingkey</code> with chosen pubkey.</p></li><li><p>Add chosen pubkey into <a href=https://dist.apache.org/repos/dist/dev/beam/KEYS>dev KEYS</a> and <a href=https://dist.apache.org/repos/dist/release/beam/KEYS>release KEYS</a></p><p><strong>NOTES</strong>: Only PMC can write into <a href=https://dist.apache.org/repos/dist/release/beam/>release repo</a> [...]
@@ -61,7 +61,9 @@ My docker hub ID is: xxx
Thanks,
Release Manager
-</code></pre><h3 id=create-a-new-version-in-jira>Create a new version in JIRA</h3><p>When contributors resolve an issue in JIRA, they are tagging it with a release that will contain their changes. With the release currently underway, new issues should be resolved against a subsequent future release. Therefore, you should create a release item for this subsequent release, as follows:</p><p><strong>Attention</strong>: Only PMC has permission to perform this. If you are not a PMC, please as [...]
+</code></pre><h3 id=create-a-new-version-in-jira>Create a new version in JIRA</h3><p>When contributors resolve an issue in JIRA, they are tagging it with a release that will contain their changes. With the release currently underway, new issues should be resolved against a subsequent future release. Therefore, you should create a release item for this subsequent release, as follows:</p><p><strong>Attention</strong>: Only PMC has permission to perform this. If you are not a PMC, please as [...]
+The role of the release manager is to file JIRA issues for each regression with the ‘Fix Version’ set to the to-be-released version. The release manager
+oversees these just like any other JIRA issue marked with the ‘Fix Version’ of the release.</p><p>The mailing list should be informed to allow fixing the regressions in the course of the release.</p><h2 id=4-create-a-release-branch-in-apachebeam-repository>4. Create a release branch in apache/beam repository</h2><p>Attention: Only committer has permission to create release branch in apache/beam.</p><p>Release candidates are built from a release branch. As a final step in prep [...]
./beam/release/src/main/scripts/cut_release_branch.sh \
--release=${RELEASE_VERSION} \
--next_release=${NEXT_VERSION}
@@ -98,7 +100,7 @@ sed -i -e "s/'beam-master-.*'/'beam-${RELEASE}'/g" runners/google-clou
Some processes, including our archetype tests, rely on having a live SNAPSHOT of the current version
from the <code>master</code> branch. Once the release branch is cut, these SNAPSHOT versions are no longer found,
so builds will be broken until a new snapshot is available.</p><p>There are 2 ways to trigger a nightly build, either using automation script(recommended), or perform all operations manually.</p><h4 id=run-start_snapshot_buildsh-to-trigger-build>Run start_snapshot_build.sh to trigger build</h4><ul><li><p>Script: <a href=https://github.com/apache/beam/blob/master/release/src/main/scripts/start_snapshot_build.sh>start_snapshot_build.sh</a></p></li><li><p>Usage</p><pre><code>./beam/release/ [...]
-</code></pre></li><li><p>The script will:</p><ol><li>Install <a href=https://github.com/github/hub>hub</a> with your agreement.</li><li>Touch an empty txt file and commit changes into <code>${your remote beam repo}/snapshot_build</code></li><li>Use hub to create a PR against apache:master, which triggers a Jenkins job to build snapshot.</li></ol></li><li><p>Tasks you need to do manually to <strong>verify the SNAPSHOT build</strong></p><ol><li>Check whether the Jenkins job gets triggered. [...]
+</code></pre></li><li><p>The script will:</p><ol><li>Install <a href=https://github.com/github/hub>hub</a> with your agreement.</li><li>Touch an empty txt file and commit changes into <code>${your remote beam repo}/snapshot_build</code></li><li>Use hub to create a PR against apache:master, which triggers a Jenkins job to build snapshot.</li></ol></li><li><p>Tasks you need to do manually to <strong>verify the SNAPSHOT build</strong></p><ol><li>Check whether the Jenkins job gets triggered. [...]
There are 2 ways to perform this verification, either running automation script(recommended), or running all commands manually.</p><p>! Dataflow tests will fail if Dataflow worker container is not created and published by this time. (Should be done by Google)</p><h4 id=run-automation-script-verify_release_buildsh>Run automation script (verify_release_build.sh)</h4><ul><li><p>Script: <a href=https://github.com/apache/beam/blob/master/release/src/main/scripts/verify_release_build.sh>verify [...]
It’ll be used by the script for accessing Github API.
You don’t have to add any permissions to this token.</li><li>Update required configurations listed in <code>RELEASE_BUILD_CONFIGS</code> in <a href=https://github.com/apache/beam/blob/master/release/src/main/scripts/script.config>script.config</a></li><li>Then run<pre><code>cd beam/release/src/main/scripts && ./verify_release_build.sh
@@ -123,15 +125,17 @@ sudo apt-get install python3.7-dev
</code></pre></li><li><p>Run build command</p><pre><code>./gradlew build -PisRelease --no-parallel --scan --stacktrace --continue
</code></pre><p>To speed things up locally you might want to omit <code>--no-parallel</code>. You can also omit <code>--continue</code>
if you want build fails after the first error instead of continuing, it may be easier and faster
-to find environment issues this way without having to wait until the full build completes.</p></li></ol></li></ul><h4 id=create-release-blocking-issues-in-jira>Create release-blocking issues in JIRA</h4><p>The verify_release_build.sh script may include failing or flaky tests. For each of the failing tests create a JIRA with the following properties:</p><ul><li><p>Issue Type: Bug</p></li><li><p>Summary: Name of failing gradle task and name of failing test (where applicable) in form of :My [...]
-Make sure they have blocker JIRAs attached and are OK to get into the release by checking with community if needed.</p><p>As the Release Manager you are empowered to accept or reject cherry-picks to the release branch. You are encouraged to ask the following questions to be answered on each cherry-pick PR and you can choose to reject cherry-pick requests if these questions are not satisfactorily answered:</p><ul><li>Is this a regression from a previous release? (If no, fix could go to a [...]
+to find environment issues this way without having to wait until the full build completes.</p></li></ol></li></ul><h4 id=create-release-blocking-issues-in-jira>Create release-blocking issues in JIRA</h4><p>The verify_release_build.sh script may include failing or flaky tests. For each of the failing tests create a JIRA with the following properties:</p><ul><li><p>Issue Type: Bug</p></li><li><p>Summary: Name of failing gradle task and name of failing test (where applicable) in form of :My [...]
+a list of pending issues and to-be-trigated issues should be included. Afterwards, this list can be refined and updated
+by the release manager and the Beam community.</p><hr><h2 id=6-triage-release-blocking-issues-in-jira>6. Triage release-blocking issues in JIRA</h2><p>There could be outstanding release-blocking issues, which should be triaged before proceeding to build a release candidate. We track them by assigning a specific <code>Fix version</code> field even before the issue resolved.</p><p>The list of release-blocking issues is available at the <a href="https://issues.apache.org/jira/browse/BEAM/?s [...]
+Make sure they have blocker JIRAs attached and are OK to get into the release by checking with community if needed.</p><p>As the Release Manager you are empowered to accept or reject cherry-picks to the release branch. You are encouraged to ask the following questions to be answered on each cherry-pick PR and you can choose to reject cherry-pick requests if these questions are not satisfactorily answered:</p><ul><li>Is this a regression from a previous release? (If no, fix could go to a [...]
</code></pre></li><li><p>The script will:</p><ol><li>Run gradle release to create rc tag and push source release into github repo.</li><li>Run gradle publish to push java artifacts into Maven staging repo.</li><li>Stage source release into dist.apache.org dev <a href=https://dist.apache.org/repos/dist/dev/beam/>repo</a>.</li><li>Stage, sign and hash python source distribution and wheels into dist.apache.org dev repo python dir</li><li>Stage SDK docker images to <a href="https://hub.docke [...]
Please note that dependencies for the SDKs with different Python versions vary.
Need to verify all Python images by replacing <code>${ver}</code> with each supported Python version <code>X.Y</code>.</li></ul><pre><code>docker run -it --entrypoint=/bin/bash apache/beam_python${ver}_sdk:${RELEASE}_rc{RC_NUM}
ls -al /opt/apache/beam/third_party_licenses/ | wc -l
</code></pre><ul><li>For Java SDK images, there should be around 1400 dependencies.</li></ul><pre><code>docker run -it --entrypoint=/bin/bash apache/beam_java_sdk:${RELEASE}_rc{RC_NUM}
ls -al /opt/apache/beam/third_party_licenses/ | wc -l
-</code></pre></li></ol></li><li>Publish staging artifacts<ol><li>Log in to the <a href=https://repository.apache.org/#stagingRepositories>Apache Nexus</a> website.</li><li>Navigate to Build Promotion -> Staging Repositories (in the left sidebar).</li><li>Select repository <code>orgapachebeam-NNNN</code>.</li><li>Click the Close button.</li><li>When prompted for a description, enter “Apache Beam, version X, release candidate Y”.</li><li>Review all staged artifacts on <a href=https://repos [...]
+</code></pre></li></ol></li><li>Publish staging artifacts<ol><li>Log in to the <a href=https://repository.apache.org/#stagingRepositories>Apache Nexus</a> website.</li><li>Navigate to Build Promotion -> Staging Repositories (in the left sidebar).</li><li>Select repository <code>orgapachebeam-NNNN</code>.</li><li>Click the Close button.</li><li>When prompted for a description, enter “Apache Beam, version X, release candidate Y”.</li><li>Review all staged artifacts on <a href=https://repos [...]
in and exclude, plus a list of offline URLs that populate links from Beam’s
Javadoc to the Javadoc for other modules that Beam depends on.</p><ul><li><p>Confirm that new modules added since the last release have been added to the
inclusion list as appropriate.</p></li><li><p>Confirm that the excluded package list is up to date.</p></li><li><p>Verify the version numbers for offline links match the versions used by Beam. If
@@ -196,7 +200,7 @@ According to git shortlog, the following people contributed to the 2.XX.0 releas
${CONTRIBUTORS}
</code></pre><h4 id=checklist-to-proceed-to-the-next-step-1>Checklist to proceed to the next step</h4><ol><li>Maven artifacts deployed to the staging repository of <a href=https://repository.apache.org/content/repositories/>repository.apache.org</a></li><li>Source distribution deployed to the dev repository of <a href=https://dist.apache.org/repos/dist/dev/beam/>dist.apache.org</a></li><li>Website pull request proposed to list the <a href=/get-started/downloads/>release</a>, publish the [...]
docker pull apache/beam_python3.5_sdk:2.16.0_rc1
-</code></pre><hr><h2 id=7-vote-and-validate-release-candidate>7. Vote and validate release candidate</h2><p>Once you have built and individually reviewed the release candidate, please share it for the community-wide review. Please review foundation-wide <a href=http://www.apache.org/foundation/voting.html>voting guidelines</a> for more information.</p><p>Start the review-and-vote thread on the dev@ mailing list. Here’s an email template; please adjust as you see fit.</p><pre><code>From: [...]
+</code></pre><hr><h2 id=9-vote-and-validate-release-candidate>9. Vote and validate release candidate</h2><p>Once you have built and individually reviewed the release candidate, please share it for the community-wide review. Please review foundation-wide <a href=http://www.apache.org/foundation/voting.html>voting guidelines</a> for more information.</p><p>Start the review-and-vote thread on the dev@ mailing list. Here’s an email template; please adjust as you see fit.</p><pre><code>From: [...]
To: dev@beam.apache.org
Subject: [VOTE] Release 1.2.3, release candidate #3
@@ -346,7 +350,7 @@ mvn compile exec:java -Dexec.mainClass=org.apache.beam.examples.complete.game.in
--temp_location=${YOUR_GS_BUCKET}/temp/ \
--sdk_location dist/* \
--fixed_window_duration ${SOME_SMALL_DURATION}
-</code></pre><p>Inspect results:</p><ul><li>Goto your Dataflow job console and check whether there is any error.</li><li>Goto your BigQuery console and check whether your ${USER}_test has game_stats_teams and game_stats_sessions table.</li><li>bq head -n 10 ${USER}_test.game_stats_teams</li><li>bq head -n 10 ${USER}_test.game_stats_sessions</li></ul></li></ul></li></ul><h3 id=fix-any-issues>Fix any issues</h3><p>Any issues identified during the community review and vote should be fixed i [...]
+</code></pre><p>Inspect results:</p><ul><li>Goto your Dataflow job console and check whether there is any error.</li><li>Goto your BigQuery console and check whether your ${USER}_test has game_stats_teams and game_stats_sessions table.</li><li>bq head -n 10 ${USER}_test.game_stats_teams</li><li>bq head -n 10 ${USER}_test.game_stats_sessions</li></ul></li></ul></li></ul><h3 id=fix-any-issues>Fix any issues</h3><p>Any issues identified during the community review and vote should be fixed i [...]
<strong>NOTE</strong>: If you are using <a href=https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/>GitHub two-factor authentication</a> and haven’t configure HTTPS access,
please follow <a href=https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/>the guide</a> to configure command line access.</p><h3 id=deploy-python-artifacts-to-pypi>Deploy Python artifacts to PyPI</h3><ul><li>Script: <a href=https://github.com/apache/beam/blob/master/release/src/main/scripts/deploy_pypi.sh>deploy_pypi.sh</a></li><li>Usage</li></ul><pre><code>./beam/release/src/main/scripts/deploy_pypi.sh
</code></pre><ul><li>Verify that the files at <a href=https://pypi.org/project/apache-beam/#files>https://pypi.org/project/apache-beam/#files</a> are correct.
@@ -356,7 +360,7 @@ All wheels should be published, in addition to the zip of the release source.
git tag -s "$VERSION_TAG" "$RC_TAG"
git push https://github.com/apache/beam "$VERSION_TAG"
</code></pre><p>After the tag is uploaded, publish the release notes to Github, as follows:</p><pre><code>cd beam/release/src/main/scripts && ./publish_github_release_notes.sh
-</code></pre><p>Note this script reads the release notes from the blog post, so you should make sure to run this from master <em>after</em> merging the blog post PR.</p><h3 id=pmc-only-finalization>PMC-Only Finalization</h3><p>There are a few release finalization tasks that only PMC members have permissions to do. Ping <a href=mailto:dev@beam.apache.org>dev@</a> for assistance if you need it.</p><h4 id=deploy-source-release-to-distapacheorg>Deploy source release to dist.apache.org</h4><p [...]
+</code></pre><p>Note this script reads the release notes from the blog post, so you should make sure to run this from master <em>after</em> merging the blog post PR.</p><h3 id=pmc-only-finalization>PMC-Only Finalization</h3><p>There are a few release finalization tasks that only PMC members have permissions to do. Ping <a href=mailto:dev@beam.apache.org>dev@</a> for assistance if you need it.</p><h4 id=deploy-source-release-to-distapacheorg>Deploy source release to dist.apache.org</h4><p [...]
<strong>NOTE</strong>: This can only be done from <code>@apache.org</code> email address.</p><h3 id=social-media>Social media</h3><p>Tweet, post on Facebook, LinkedIn, and other platforms. Ask other contributors to do the same.</p><p>Also, update <a href=https://en.wikipedia.org/wiki/Apache_Beam>the Wikipedia article on Apache Beam</a>.</p><h3 id=checklist-to-declare-the-process-completed>Checklist to declare the process completed</h3><ol><li>Release announced on the user@ mailing list.< [...]
<a href=http://www.apache.org>The Apache Software Foundation</a>
| <a href=/privacy_policy>Privacy Policy</a>
diff --git a/website/generated-content/sitemap.xml b/website/generated-content/sitemap.xml
index d40fc14..2143d73 100644
--- a/website/generated-content/sitemap.xml
+++ b/website/generated-content/sitemap.xml
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"><url><loc>/blog/beam-2.23.0/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/categories/blog/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/blog/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/categories/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/blog/b [...]
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"><url><loc>/blog/beam-2.23.0/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/categories/blog/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/blog/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/categories/</loc><lastmod>2020-07-29T14:52:28-07:00</lastmod></url><url><loc>/blog/b [...]
\ No newline at end of file