|
| 1 | +# OpenTelemetry Release Process |
| 2 | + |
| 3 | +## Tagging the Release |
| 4 | + |
| 5 | +The first step in the release process is to create a release branch, bump versions, and create a tag |
| 6 | +for the release. Our release branches follow the naming convention of v<major>.<minor>.x, while the |
| 7 | +tags include the patch version v<major>.<minor>.<patch>. For example, the same branch v0.3.x would |
| 8 | +be used to create all v0.3.* tags (e.g. v0.3.0, v0.3.1). |
| 9 | + |
| 10 | +In this section upstream repository refers to the main opentelemetry-java github repository. |
| 11 | + |
| 12 | +Before any push to the upstream repository you need to create a |
| 13 | +[personal access token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line). |
| 14 | + |
| 15 | +1. Create the release branch and push it to GitHub: |
| 16 | + |
| 17 | + ```bash |
| 18 | + $ MAJOR=0 MINOR=4 PATCH=0 # Set appropriately for new release |
| 19 | + $ VERSION_FILES=( |
| 20 | + build.gradle |
| 21 | + ) |
| 22 | + $ git checkout -b v$MAJOR.$MINOR.x master |
| 23 | + $ git push upstream v$MAJOR.$MINOR.x |
| 24 | + ``` |
| 25 | + The branch will be automatically protected by the GitHub branch protection rule for release |
| 26 | + branches. |
| 27 | + |
| 28 | +2. For `master` branch: |
| 29 | + |
| 30 | + - Change root build files to the next minor snapshot (e.g. |
| 31 | + `0.4.0-SNAPSHOT`). |
| 32 | + |
| 33 | + ```bash |
| 34 | + $ git checkout -b bump-version master |
| 35 | + # Change version to next minor (and keep -SNAPSHOT) |
| 36 | + $ sed -i 's/[0-9]\+\.[0-9]\+\.[0-9]\+\(.*CURRENT_OPEN_TELEMETRY_VERSION\)/'$MAJOR.$((MINOR+1)).0'\1/' \ |
| 37 | + "${VERSION_FILES[@]}" |
| 38 | + $ ./gradlew build |
| 39 | + $ git commit -a -m "Start $MAJOR.$((MINOR+1)).0 development cycle" |
| 40 | + ``` |
| 41 | + |
| 42 | + - Go through PR review and push the master branch to GitHub. |
| 43 | + |
| 44 | +3. For `vMajor.Minor.x` branch: |
| 45 | + |
| 46 | + - Change root build files to remove "-SNAPSHOT" for the next release |
| 47 | + version (e.g. `0.3.0`). Commit the result and make a tag: |
| 48 | + |
| 49 | + ```bash |
| 50 | + $ git checkout -b release v$MAJOR.$MINOR.x |
| 51 | + # Change version to remove -SNAPSHOT |
| 52 | + $ sed -i 's/-SNAPSHOT\(.*CURRENT_OPEN_TELEMETRY_VERSION\)/\1/' "${VERSION_FILES[@]}" |
| 53 | + $ ./gradlew build |
| 54 | + $ git commit -a -m "Bump version to $MAJOR.$MINOR.$PATCH" |
| 55 | + $ git tag -a v$MAJOR.$MINOR.$PATCH -m "Version $MAJOR.$MINOR.$PATCH" |
| 56 | + ``` |
| 57 | + |
| 58 | + - Change root build files to the next snapshot version (e.g. |
| 59 | + `0.3.1-SNAPSHOT`). Commit the result: |
| 60 | + |
| 61 | + ```bash |
| 62 | + # Change version to next patch and add -SNAPSHOT |
| 63 | + $ sed -i 's/[0-9]\+\.[0-9]\+\.[0-9]\+\(.*CURRENT_OPEN_TELEMETRY_VERSION\)/'$MAJOR.$MINOR.$((PATCH+1))-SNAPSHOT'\1/' \ |
| 64 | + "${VERSION_FILES[@]}" |
| 65 | + $ ./gradlew build |
| 66 | + $ git commit -a -m "Bump version to $MAJOR.$MINOR.$((PATCH+1))-SNAPSHOT" |
| 67 | + ``` |
| 68 | + |
| 69 | + - Go through PR review and push the release tag and updated release branch |
| 70 | + to GitHub (note: do not squash the commits when you merge otherwise you |
| 71 | + will lose the release tag): |
| 72 | + |
| 73 | + ```bash |
| 74 | + $ git checkout v$MAJOR.$MINOR.x |
| 75 | + $ git merge --ff-only release |
| 76 | + $ git push upstream v$MAJOR.$MINOR.$PATCH |
| 77 | + $ git push upstream v$MAJOR.$MINOR.x |
| 78 | + ``` |
| 79 | + |
| 80 | +## Announcement |
| 81 | + |
| 82 | +Once deployment is done by Circle CI (controlled by the Bintray plugin) , go to Github [release |
| 83 | +page](https://github.com/open-telemetry/opentelemetry-java/releases), press |
| 84 | +`Draft a new release` to write release notes about the new release. |
| 85 | + |
| 86 | +You can use `git log upstream/v$MAJOR.$((MINOR-1)).x..upstream/v$MAJOR.$MINOR.x --graph --first-parent` |
| 87 | +or the Github [compare tool](https://github.com/open-telemetry/opentelemetry-java/compare/) |
| 88 | +to view a summary of all commits since last release as a reference. |
| 89 | + |
| 90 | +In addition, you can refer to |
| 91 | +[CHANGELOG.md](https://github.com/open-telemetry/opentelemetry-java/blob/master/CHANGELOG.md) |
| 92 | +for a list of major changes since last release. |
| 93 | + |
| 94 | +## Update release versions in documentations and CHANGELOG files |
| 95 | + |
| 96 | +After releasing is done, you need to update |
| 97 | +[README.md](https://github.com/open-telemetry/opentelemetry-java/blob/master/README.md) and |
| 98 | +[CHANGELOG.md](https://github.com/open-telemetry/opentelemetry-java/blob/master/CHANGELOG.md). |
| 99 | + |
| 100 | +Create a PR to mark the new release in |
| 101 | +[CHANGELOG.md](https://github.com/census-instrumentation/opencensus-java/blob/master/CHANGELOG.md) |
| 102 | +on master branch. |
| 103 | + |
| 104 | +## Patch Release |
| 105 | + |
| 106 | +All patch releases should include only bug-fixes, and must avoid |
| 107 | +adding/modifying the public APIs. To cherry-pick one commit use the following |
| 108 | +instructions: |
| 109 | + |
| 110 | +- Create and push a tag: |
| 111 | + |
| 112 | +```bash |
| 113 | +COMMIT=1224f0a # Set the right commit hash. |
| 114 | +git checkout -b cherrypick v$MAJOR.$MINOR.x |
| 115 | +git cherry-pick -x $COMMIT |
| 116 | +git commit -a -m "Cherry-pick commit $COMMIT" |
| 117 | +``` |
| 118 | + |
| 119 | +- Go through PR review and merge it to GitHub v$MAJOR.$MINOR.x branch. |
| 120 | + |
| 121 | +- Tag a new patch release when all commits are merged. |
| 122 | + |
| 123 | +## Release candidates |
| 124 | + |
| 125 | +Release candidate artifacts are released using the same process described above. The version schema for release candidates |
| 126 | +is`v1.2.3-RC$`, where `$` denotes a release candidate version, e.g. `v1.2.3-RC1`. |
| 127 | + |
| 128 | +## Credentials |
| 129 | + |
| 130 | +The following credentials are required for publishing (and automatically set in Circle CI): |
| 131 | + |
| 132 | +* `BINTRAY_USER` and `BINTRAY_KEY`: Bintray username and API Key. |
| 133 | + See [this](https://www.jfrog.com/confluence/display/BT/Bintray+Security#BintraySecurity-APIKeys). |
| 134 | + |
| 135 | +* `SONATYPE_USER` and `SONATYPE_KEY`: Sonatype username and password. |
| 136 | + |
| 137 | +## Releasing from the local setup |
| 138 | + |
| 139 | +Releasing from the local setup can be done providing the previously mentioned four credential values, i.e. |
| 140 | +`BINTRAY_KEY`, `BINTRAY_USER`, `SONATYPE_USER` and `SONATYPE_KEY`: |
| 141 | + |
| 142 | +```sh |
| 143 | +export BINTRAY_USER=my_bintray_user |
| 144 | +export BINTRAY_KEY=my_user_api_key |
| 145 | +export SONATYPE_USER=my_maven_user |
| 146 | +export SONATYPE_KEY=my_maven_password |
| 147 | +make publish-release-artifacts |
| 148 | +``` |
0 commit comments