Skip to content

Commit

Permalink
Swap steps to update master branch before cutting release branch
Browse files Browse the repository at this point in the history
  • Loading branch information
@errose28
errose28 committed Feb 1, 2024
1 parent 4c809d1 commit 228322e
Showing 1 changed file with 61 additions and 52 deletions.
113 changes: 61 additions & 52 deletions docs/08-developer-guide/04-project/02-release-guide.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -73,9 +73,59 @@ Issue a Jira query like [this](https://issues.apache.org/jira/issues/?jql=projec
:::
7. Keep clicking through until the operation is started. It may take a while for Jira to finish the bulk update once it is started.

Wait for the date specified in the Jira comments to pass and blocking issues to be resolved before proceeding with the next steps to update the master branch and cut a release branch.

### Build and Commit `proto.lock` Files to the Master Branch

Protolock files are used to check backwards compatibility of protocol buffers between releases. The Ozone build checks protocol buffers against these lock files and fails if an incompatibility is detected. They should be updated for each release, and require [protolock](https://github.com/nilslice/protolock) to be installed.

1. Save and run the following script from your Ozone repo root.

```bash title="update_protolocks.sh"
#!/usr/bin/env sh

for lock in $(find . -name proto.lock); do
lockdir="$(dirname "$lock")"
protoroot="$lockdir"/../proto
if protolock status --lockdir="$lockdir" --protoroot="$protoroot"; then
protolock commit --lockdir="$lockdir" --protoroot="$protoroot"
else
echo "protolock update failed for $protoroot"
fi
done
```

2. Commit changes to the `proto.lock` files.
```bash
git commit -m "Update proto.lock for Ozone $VERSION"
```

:::warning
Double check that only files called `proto.lock` are being committed, and that the changes to the files makes sense based on new features added in this release.
:::

:::tip
Ozone currently uses the following protolock files:
- `hadoop-hdds/interface-client/src/main/resources/proto.lock`: Controls the protocol for clients communicating with datanodes.
- `hadoop-hdds/interface-admin/src/main/resources/proto.lock`: Controls the protocol for clients communicating with SCM.
- `hadoop-hdds/interface-server/src/main/resources/proto.lock`: Controls the protocol for SCMs communicating with each other.
- `hadoop-ozone/interface-client/src/main/resources/proto.lock`: Controls all protocols involving the Ozone Manager.
- `hadoop-ozone/csi/src/main/resources/proto.lock`: Controls the protocol for the Ozone CSI server.
:::

3. Submit a pull request to add the updated `proto.lock` changes to Ozone's master branch. This commit will be the parent of your release branch.
### Update the Ozone Version on the Master Branch
Update the Ozone SNAPSHOT version and national park tag on master with a pull request. The snapshot version should be set to one minor version after the current release. For example, if you are releasing 1.4.0, then the master branch's current version would be `1.4.0-SNAPSHOT`. Here you would increase it to `1.5.0-SNAPSHOT`. As part of this change, you will pick the [United States National Park](https://en.wikipedia.org/wiki/List_of_national_parks_of_the_United_States) to use for the next release of Ozone and set it in the project's top level pom at `<ozone.release>`. See [this pull request](https://github.com/apache/ozone/pull/2863) for an example.
### Create a Release Branch
After the date specified in the Jira comments has passed and blocking issues have been resolved, you can create a release branch in the [apache/ozone](https://github.com/apache/ozone) Github repo. Name the branch after the major and minor version of the release, so patch releases can also be done off this branch. For example, If releasing 1.2.0, create a branch called `ozone-1.2` . All release related changes will go to this branch until the release is complete, after which some changes mentioned below will be cherry picked to `master`.
Once the previous two pull requests to update protolock files and the Ozone SNAPSHOT version are merged, you can create a release branch in the [apache/ozone](https://github.com/apache/ozone) Github repo.
:::important
The parent commit of the release branch should be the commit that was merged in the [proto.lock file update](#build-and-commit-protolock-files-to-the-master-branch).
:::
Name the branch after the major and minor version of the release, so patch releases can also be done off this branch. For example, If releasing 1.2.0, create a branch called `ozone-1.2` . All release related changes will go to this branch until the release is complete.
### Set Up Local Environment
Expand All @@ -88,16 +138,17 @@ export CODESIGNINGKEY=<your_gpg_key_id>
export RC=0 # Set to the number of the current release candidate, starting at 0.
```
It is probably best to clone a fresh ozone repository locally to work on the release, and leave your existing repository intact for dev tasks you may be working on simultaneously. After cloning, make sure the git remote for the apache/ozone upstream repo is named `origin`. This is required for release build metadata to be correctly populated. Assume all following commands are executed from within this repo with your release branch checked out.

### Reset the Git Repository
It is probably best to clone a fresh Ozone repository locally to work on the release, and leave your existing repository intact for dev tasks you may be working on simultaneously. After cloning, make sure the git remote for the [apache/ozone](https://github.com/apache/ozone) upstream repo is named `origin`. This is required for release build metadata to be correctly populated.
Run the following commands to make sure your repo is clean:
```bash
git reset --hard
git clean -dfx
```
### Update the Versions
Assume all following commands are executed from within this repo with your release branch checked out.
### Update the Ozone Version on the Release Branch
Use the commands below or your IDE to replace `$VERSION-SNAPSHOT` with `$VERSION`.
Expand All @@ -121,44 +172,6 @@ find . -name pom.xml -type f -print0 | xargs -0 sed -i '' "s/$VERSION-SNAPSHOT/$
git commit -am "Update Ozone version to $VERSION"
```
### Build and Commit the `proto.lock` Change

Protolock files are used to check backwards compatibility of protocol buffers between releases. The Ozone build checks protocol buffers against these lock files and fails if an incompatibility is detected. They should be updated for each release, and require [protolock](https://github.com/nilslice/protolock) to be installed.

1. Save and run the following script from your Ozone repo root.

```bash title="update_protolocks.sh"
#!/usr/bin/env sh

for lock in $(find . -name proto.lock); do
lockdir="$(dirname "$lock")"
protoroot="$lockdir"/../proto
if protolock status --lockdir="$lockdir" --protoroot="$protoroot"; then
protolock commit --lockdir="$lockdir" --protoroot="$protoroot"
else
echo "protolock update failed for $protoroot"
fi
done
```

2. Commit changes to the `proto.lock` files.
```bash
git commit -m "Update proto.lock for Ozone $VERSION"
```

:::warning
Double check that only files called `proto.lock` are being committed, and that the changes to the files makes sense based on new features added in this release.
:::

:::tip
Ozone currently uses the following protolock files:
- `hadoop-hdds/interface-client/src/main/resources/proto.lock`: Controls the protocol for clients communicating with datanodes.
- `hadoop-hdds/interface-admin/src/main/resources/proto.lock`: Controls the protocol for clients communicating with SCM.
- `hadoop-hdds/interface-server/src/main/resources/proto.lock`: Controls the protocol for SCMs communicating with each other.
- `hadoop-ozone/interface-client/src/main/resources/proto.lock`: Controls all protocols involving the Ozone Manager.
- `hadoop-ozone/csi/src/main/resources/proto.lock`: Controls the protocol for the Ozone CSI server.
:::

### Tag the Commit for the Release Candidate
This will sign the tag with the GPG key matching the git mailing address. Make sure that the email given by `git config user.email` matches the email for the key you want to use shown by `gpg --list-secret-keys`.
Expand Down Expand Up @@ -394,16 +407,12 @@ The Ozone docker image is intended for testing purposes only, not production use
git push origin "ozone-$VERSION"
```
### Update the Master Branch
### Update Acceptance Tests on the Master Branch
1. Cherry pick your commit updating the protolock files to a branch on your fork, and merge it to master with a pull request.

2. Update the Ozone SNAPSHOT version and national park tag on master with a pull request. Here you will pick the [United States National Park](https://en.wikipedia.org/wiki/List_of_national_parks_of_the_United_States) to use for the next release of Ozone and set it in the project's top level pom at `<ozone.release>`. See [this pull request](https://github.com/apache/ozone/pull/2863) for an example.
3. Update the upgrade and client cross compatibility acceptance tests to check against the new release. See [this pull request](https://github.com/apache/ozone/pull/6040/files) for an example.
:::note
This step requires the release's [docker image](#publish-a-docker-image-for-the-release) to be published.
:::
Update the upgrade and client cross compatibility acceptance tests to check against the new release. See [this pull request](https://github.com/apache/ozone/pull/6040/files) for an example.
:::note
This step requires the release's [docker image](#publish-a-docker-image-for-the-release) to be published.
:::

### Update the Ozone Roadmap

Expand Down

0 comments on commit 228322e

Please sign in to comment.