Skip to content

How to release

Jump to bottom
Raúl Gracia edited this page Nov 13, 2019 · 20 revisions

About this repository

Before describing the release process, it is necessary to understand how this repository is organized.

In pravega-samples, the main branch is dev: all the pull requests with new code changes should target dev branch. This differs from other repositories (e.g., pravega), where the main branch is master. On the other hand, master branch in pravega-samples mirrors the state of the highest available release. The main reason for this is that we want users cloning this repository to work by default with the most recent release of both pravega and the pravega-flink/hadoop-connectors.

Preparing the branch

Preparing the branch consists of making any necessary changes to the branch you will be working on as part of releasing. There are two possible situations:

  • Major release: This is a change to either the first or the middle digit, and it requires a new release branch.

  • Bug-fix release: This is a minor release version over an existing release branch

Important: At the moment, the release of pravega-samples depends on the release of pravega, flink-connectors, hadoop-connectors, and pravega-keycloak. Please, do not start the release process until such dependencies have been released.

Major release

Here we describe the steps to create a major release. Let's assume that the version we want to release is x.y.0.

  1. Tag the current commit point of the dev branch:
git checkout dev
git tag branch-x.y
git push origin branch-x.y

  1. Create an issue to update dev branch artifacts to the release version. At the moment, the artifacts version in gradle.properties should be of the form x.y.0-abc-SNAPSHOT. This issue should describe the need to change the artifacts to its release form x.y.0. For an example, please look this one.

  2. Create a PR addressing the previous issue. That is, from your own fork and assuming that your local your_fork:dev branch is in sync with pravega-samples:dev branch, the PR should update gradle.properties:

pravegaVersion=x.y.0
pravegaKeycloakVersion=x.y.0
flinkConnectorVersion=x.y.0
samplesVersion=x.y.0
hadoopConnectorVersion=x.y.0

For an example, please have a look to this PR.

  1. Create an issue to denote the need for creating a new release branch rx.y. You can see an example here.

  2. Address the previous issue by creating a release branch and tagging it:

git pull
git checkout -b rx.y
git push origin rx.y
git checkout rx.y
git tag vx.y.0
git push origin vx.y.0

  1. Create release candidate on GitHub. On the GitHub repository page, go to releases and create a new draft. Fill out the recently created tag vx.y.0 and then fill the title and short release notes.

  2. Publish the release candidate from GitHub. Once this is all done, publish the release candidate by clicking on the button on the draft page.

  3. At the beginning of this page, we mentioned that the pravega-samples:master branch should reflect the state of the release with the highest number. As this is a major release, this must be the highest release number. Therefore, we need to create an issue to merge the release branch rx.y into master.

  4. Create a PR to address the previous issue. One way to approach this is to synchronize your local fork to be sure that you see branch local_fork:r0.3. Then, create a PR from local_fork:r0.3 to pravega-samples:master. This will update pravega-samples:master with all the code changed from dev and the correct release artifact version in gradle.properties. Very important: We want to keep the same history of commits in dev and master. For this reason, when merging the changes from dev to master, do it with the MERGE COMMIT option (if you do SQUASH AND MERGE, all the ids for the commits will differ between master and dev, and this will make impossible to merge again changes from dev to master cleanly).

  5. Create a new issue to update dev branch to the artifacts for the new major version to come. You can see an example here.

  6. Create a PR to address the previous issue. This PR should at least update gradle.properties of pravega_samples:dev branch as follows:

samplesVersion=x.(y+1).0-SNAPSHOT 
or 
samplesVersion=(x+1).0.0-SNAPSHOT

Depending on the new version number to come.

Moreover, normally the artifact from the other projects would have been updated as well. For this reason, we can update the snapshot version for the Pravega components as follows (assuming new version is x.(y+1).0):

pravegaVersion=x.(y+1).0-abc-SNAPSHOT
pravegaKeycloakVersion=x.(y+1).0-abc-SNAPSHOT
flinkConnectorVersion=x.(y+1).0-abc-SNAPSHOT
hadoopConnectorVersion=x.(y+1).0-abc-SNAPSHOT

The actual artifact id (x.(y+1).0-abc-SNAPSHOT) is available in the Pravega jFrog repository where snapshots are published. Please, check the most recent version to correctly set these values for each artifact.

Bugfix release

In a bugfix release, we work on top of the release branch created in a previous major release rx.y. The objective is to update the existing branch to a new tag vx.y.(z+1) and cherry-pick changed from dev branch in the case it is necessary. The steps are the following:

  1. Create an issue to update gradle.properties in branch rx.y from x.y.z to x.y.(z+1). For an example, please look at this issue.

  2. Create a PR addressing the previous issue and update gradle.properties:

pravegaVersion=x.y.z -> x.y.(z+1)
pravegaKeycloakVersion=x.y.z -> x.y.(z+1)
flinkConnectorVersion=x.y.z -> x.y.(z+1)
samplesVersion=x.y.z -> x.y.(z+1)

For an example, we refer to this PR.

  1. (Optional) This is an optional step in the case you want to add some code changes from dev branch to rx.y branch (not always necessary). In the affirmative case, create a new issue describing the commits from dev branch that should be integrated in rx.y.

  2. (Only if previous step is done) Synchronize your local_fork:r0.3 with pravega-samples:r0.3 and then perform git cherry-pick {commit_id} on all the commits you want to include in this bugfix release from pravega-samples:dev. Note that the commit ids should be cherry-picked sequentially from the oldest to the newest, in the case that there are multiple commits to be integrated. Create a new PR from local_fork:r0.3 targeting pravega-samples:r0.3 including all the cherry-picked commits.

  3. After merging the previous PR, tag the current release branch rx.y as vx.y.(z+1). Thus, assuming that you are cloning pravega-samples (which is where origin points to):

git tag vx.y.(z+1)
git push origin vx.y.(z+1)

  1. Create release candidate on GitHub. On the GitHub repository page, go to releases and create a new draft. Fill out the recently created tag vx.y.(z+1) and then fill the title and short release notes.

  2. Publish the release candidate from GitHub. Once this is all done, publish the release candidate by clicking on the button on the draft page.

  3. (Optional) As defined at the beginning of this page, the pravega-samples:master branch should reflect the state of the release with highest version number. Therefore, if the bugfix release version is the highest one, then we should mirror the state of r0.3 in master. First, create an issue that describes this task as this one.

  4. (Only if previous step is done) Create a PR to address the previous issue. One way to approach this is to synchronize your local fork to be sure that you see branch local_fork:r0.3. Then, create a PR from local_fork:r0.3 to pravega-samples:master. This will update pravega-samples:master with all the code changed in r0.3 and the correct release artifact version in gradle.properties. You can see an example here. Very important: We want to keep the same history of commits in dev and master. For this reason, when merging the changes from dev/release_branch to master, do it with the MERGE COMMIT option (if you do SQUASH AND MERGE, all the ids for the commits will differ between master and dev, and this will make impossible to merge again changes from dev to master cleanly).

  5. Create a new issue to update pravega-samples:rx.y branch to increase samplesVersion in gradle.properties. You can see an example here.

  6. Create a PR to address the previous issue. This PR should at least update gradle.properties of pravega_samples:rx.y branch as follows:

samplesVersion=x.y.(z+2)-SNAPSHOT

For an example, please have a look at this PR.

Clone this wiki locally