THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block |
|---|
Subject: Preparing Ambari X.Y.Z branch Hi developers and PMCs, I am proposing cutting thea new branch branch-X.Y for Ambari X.Y.Z on __________ as per the outlined tasks in the Ambari Feature + Roadmap page (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705). After making the branch, we (i.e., development community) should only accept blocker or critical bug fixes into the branch and harden it until it meets a high enough quality bar. If you have a bug fix, it should first be committed to trunk, and after ensuring that it does not break any tests (including smoke tests), then it should be integrated to the Ambari branch-X.Y.Z branch. If you have any doubts whether a fix should be committed into the branch-X.Y.Z branch, please email me for input at ____________ Stay tuned for updates on the release process. Thanks |
...
Create a branch for a release using branch-X.Y (ex: branch-2.1) as the name of the branch.
Note: Going forward, we should be creating branch-{majorVersion}.{minorVersion), so that the same branch can be used for maintenance releases.
Checkout the release branch
...
| Code Block |
|---|
Steps followed for 2.0.0 release as a reference
# Update the release version
mvn versions:set -DnewVersion=2.0.0.0
pushd ambari-metrics
mvn versions:set -DnewVersion=2.0.0.0
popd
pushd contrib/ambari-log4j
mvn versions:set -DnewVersion=2.0.0.0
popd
pushd contrib/ambari-scom
mvn versions:set -DnewVersion=2.0.0.0
popd
pushd docs
mvn versions:set -DnewVersion=2.0.0.0
popd
# Update the ambari.version properties in all pom.xml
$grep -r --include "pom.xml" "ambari.version" .
./ambari-web/pom.xml: <arg value="${basedir}${dirsep}set-ambari-version.${fileextension.shell}"/>
./contrib/ambari-scom/ambari-scom-server/pom.xml: <ambari.version>1.3.0-SNAPSHOT</ambari.version>
./contrib/ambari-scom/ambari-scom-server/pom.xml: <version>${ambari.version}</version>
./contrib/views/hive/pom.xml: <ambari.version>1.3.0-SNAPSHOT</ambari.version>
./contrib/views/jobs/pom.xml: <version>${ambari.version}</version>
./contrib/views/pig/pom.xml: <ambari.version>2.0.0-SNAPSHOT</ambari.version>
./contrib/views/pom.xml: <ambari.version>2.0.0-SNAPSHOT</ambari.version>
./contrib/views/tez/pom.xml: <version>${ambari.version}</version>
./docs/pom.xml: <ambari.version>1.0.0-SNAPSHOT</ambari.version>
./docs/pom.xml: <final.name>${project.artifactId}-${ambari.version}</final.name>
# Update any 2.0.0-SNAPSHOT references in pom.xml
$ grep -r --include "pom.xml" "2.0.0-SNAPSHOT" .
./ambari-views/examples/property-validator-view/pom.xml: <version>2.0.0-SNAPSHOT</version>
# Remove .versionsBackup files
git clean -f -x -d
# Review and commit the changes to branch-X.Y.Z
git commit |
Update KEYS
If this is the first time you have taken release management responsibilities, make sure to update the KEYS file and commit the updated KEYS in both the ambari trunk branch and the release branch. Also in addition to updating the KEYS file in the tree, you also need to push the KEYS file to https://dist.apache.org/repos/dist/release/ambari/
...
| Code Block |
|---|
git checkout branch-X.Y.Z
|
Create a Release Tag from the release branch
...