This is an automated email from the ASF dual-hosted git repository. mikhail pushed a commit to branch Ardagan-patch-1 in repository https://gitbox.apache.org/repos/asf/beam.git
commit ae4c5993352016f023a2cdae467efcd8faf3644f Author: Mikhail Gryzykhin <[email protected]> AuthorDate: Fri Jan 10 12:03:51 2020 -0800 Update release guide with extended information. --- website/src/contribute/release-guide.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/website/src/contribute/release-guide.md b/website/src/contribute/release-guide.md index 40dd143..583ea29 100644 --- a/website/src/contribute/release-guide.md +++ b/website/src/contribute/release-guide.md @@ -125,7 +125,7 @@ __NOTE__: When generating the key, please make sure you choose the key type as _ * Determine your Apache GPG Key and Key ID, as follows: - gpg --list-keys + gpg --list-sigs --keyid-format LONG This will list your GPG keys. One of these should reflect your Apache account, for example: @@ -377,12 +377,15 @@ There are 2 ways to trigger a nightly build, either using automation script(reco 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. +! Dataflow tests will fail if Dataflow worker container is not created and published by this time. (Should be done by Google) + #### Run automation script (verify_release_build.sh) * Script: [verify_release_build.sh](https://github.com/apache/beam/blob/master/release/src/main/scripts/verify_release_build.sh) * Usage 1. Create a personal access token from your Github account. See instruction [here](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line). It'll be used by the script for accessing Github API. + You don't have to add any permissions to this token. 1. Update required configurations listed in `RELEASE_BUILD_CONFIGS` in [script.config](https://github.com/apache/beam/blob/master/release/src/main/scripts/script.config) 1. Then run ``` @@ -595,6 +598,9 @@ For this step, we recommend you using automation script to create a RC, but you 1. Update last release download links in `website/src/get-started/downloads.md`. 1. Update `website/src/.htaccess` to redirect to the new version. 1. Build and stage python wheels. + 1. Public staging artifacts + 1. Go to the staging repo to close the staging repository on [Apache Nexus](https://repository.apache.org/#stagingRepositories). + 1. When prompted for a description, enter “Apache Beam, version X, release candidate Y”. ### (Alternative) Run all steps manually @@ -946,7 +952,7 @@ Start the review-and-vote thread on the dev@ mailing list. Here’s an email tem If there are any issues found in the release candidate, reply on the vote thread to cancel the vote. There’s no need to wait 72 hours. Proceed to the `Fix Issues` step below and address the problem. However, some issues don’t require cancellation. For example, if an issue is found in the website pull request, just correct it on the spot and the vote can continue as-is. -If there are no issues, reply on the vote thread to close the voting. Then, tally the votes in a separate email. Here’s an email template; please adjust as you see fit. +If there are no issues, reply on the vote thread to close the voting. Then, tally the votes in a separate email thread. Here’s an email template; please adjust as you see fit. From: Release Manager To: [email protected] @@ -1237,7 +1243,7 @@ Once the release candidate has been reviewed and approved by the community, the ### Deploy artifacts to Maven Central Repository -Use the Apache Nexus repository to release the staged binary artifacts to the Maven Central repository. In the `Staging Repositories` section, find the relevant release candidate `orgapachebeam-XXX` entry and click `Release`. Drop all other release candidates that are not being released. +Use the [Apache Nexus repository manager](https://repository.apache.org/#stagingRepositories) to release the staged binary artifacts to the Maven Central repository. In the `Staging Repositories` section, find the relevant release candidate `orgapachebeam-XXX` entry and click `Release`. Drop all other release candidates that are not being released. __NOTE__: If you are using [GitHub two-factor authentication](https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/) and haven't configure HTTPS access, please follow [the guide](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) to configure command line access. @@ -1248,6 +1254,14 @@ please follow [the guide](https://help.github.com/articles/creating-a-personal-a delete the `.asc`, `.sha512`; 3. Upload the new release `twine upload *` from the directory with the `.zip` and `.whl` files; +[Installing twine](https://packaging.python.org/tutorials/packaging-projects/): +``` +virtualenv env +. ./env/bin/activate +pip install twine +``` + + #### Deploy source release to dist.apache.org Copy the source release from the `dev` repository to the `release` repository at `dist.apache.org` using Subversion. @@ -1279,7 +1293,7 @@ Create and push a new signed tag for the released version by copying the tag for ### Merge website pull request -Merge the website pull request to [list the release]({{ site.baseurl }}/get-started/downloads/), publish the [Python API reference manual](https://beam.apache.org/releases/pydoc/), and the [Java API reference manual](https://beam.apache.org/releases/javadoc/) created earlier. +Merge the website pull request to [list the release]({{ site.baseurl }}/get-started/downloads/), publish the [Python API reference manual](https://beam.apache.org/releases/pydoc/), the [Java API reference manual](https://beam.apache.org/releases/javadoc/) and Blogpost created earlier. ### Mark the version as released in JIRA
