This is an automated email from the ASF dual-hosted git repository. mergebot-role pushed a commit to branch mergebot in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit 8323673ed5d2bf615bf80dec7a5816ed88c674cf Author: Pablo <[email protected]> AuthorDate: Fri Apr 20 10:50:56 2018 -0700 Addressing comments. Improving commands. --- src/contribute/release-guide.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/contribute/release-guide.md b/src/contribute/release-guide.md index 3d6b5cc..e6a3792 100644 --- a/src/contribute/release-guide.md +++ b/src/contribute/release-guide.md @@ -180,12 +180,13 @@ Javadoc to the Javadoc for other modules that Beam depends on. ### Create a release branch -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 code repository, and update version information on the original branch. +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. Check out the version of the codebase from which you start the release. For a new minor or major release, this may be `HEAD` of the `master` branch. To build a hotfix/incremental release, instead of the `master` branch, use the release tag of the release being patched. (Please make sure your cloned repository is up-to-date before starting.) git checkout <master branch OR release tag> +**NOTE**: If you are doing an incremental/hotfix release (e.g. 2.5.1), please check out the previous release tag, rather than the master branch. Set up a few environment variables to simplify Maven commands that follow. (We use `bash` Unix syntax in this guide.) @@ -195,7 +196,7 @@ Set up a few environment variables to simplify Maven commands that follow. (We u Version represents the release currently underway, while next version specifies the anticipated next version to be released from that branch. Normally, 1.2.0 is followed by 1.3.0, while 1.2.3 is followed by 1.2.4. -**NOTE**: Only if you are doing an incremental/hotfix releasei (e.g. 2.5.1), please check out the previous release tag, before running the following instructions: +**NOTE**: Only if you are doing an incremental/hotfix release (e.g. 2.5.1), please check out the previous release tag, before running the following instructions: BASE_RELEASE=2.5.0 RELEASE=2.5.1 @@ -207,9 +208,9 @@ Create a new branch, and update version files in the master branch. git branch ${BRANCH} # Now change the version in existing gradle files, and Python files - sed -i 's/'$RELEASE'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g' build_rules.gradle - sed -i 's/'$RELEASE'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g' gradle.properties - sed -i 's/'$RELEASE'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g' sdks/python/apache_beam/version.py + sed -i -e "s/'${RELEASE}'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g" build_rules.gradle + sed -i -e "s/'${RELEASE}'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g" gradle.properties + sed -i -e "s/'${RELEASE}'/'${NEXT_VERSION_IN_BASE_BRANCH}'/g" sdks/python/apache_beam/version.py # Save changes in master branch git add gradle.properties build_rules.gradle -- To stop receiving notification emails like this one, please contact [email protected].
