Skip to content

Release Process

Jump to bottom
Cassie Coyle edited this page Sep 19, 2025 · 42 revisions

Overview

The Dapr Java SDK release process is highly automated and follows a structured approach to ensure quality and consistency. Only Java maintainers or members of the Dapr release team may release the Java SDK.

Prerequisites

  • Authorization: Only Java maintainers or members of the Dapr release team can create releases
  • GitHub Actions Access: Access to the Create a release GitHub Actions workflow
  • Branch Strategy: Always branch from master - the automation script is smart enough to determine the correct branch based on the version input

Release Workflow

1. Release Candidate (RC) Process

Always release an RC first before creating the official release.

  1. Create Release Candidate:

    • Go to GitHub Actions → Create a release workflow
    • Click Run workflow
    • Input the RC version (e.g., 1.14.0-rc-1)
    • Important: Always leave the branch as master when inputting the version
    • The automation will:
      • Create the release branch (release-1.14)
      • Generate the RC tag (v1.14.0-rc-1)
      • Update version numbers automatically

  2. RC Validation:

    • Users validate the bugfix and/or feature in the RC
    • Monitor for any issues or feedback
    • If issues are found, create additional RCs (e.g., 1.14.0-rc-2)

  3. Post-RC Work:

    • If work needs to be included after the RC is cut, cherry-pick commits into the release branch
    • Do not merge directly to master for release-specific changes, they should be merged to the release branch and then once the release is officially cut one PR should merge back the changes from the release branch back into master

2. Official Release Process

  1. Create Official Release:

    • Once RC validation is complete, go to GitHub Actions → Create a release workflow
    • Input the official version (e.g., 1.14.0)
    • Important: Always leave the branch as master when inputting the version
    • The automation will:
      • Use the existing release branch
      • Generate the official tag (v1.14.0)
      • Automatically generate and update Javadocs
      • Publish to Maven Central

  2. Monitor Build Status:

    • After creating the release, monitor for 2 builds:
      • One for the release branch
      • One for the tag
    • Ensure both builds are green and successfully published

  3. Create Release Notes:

    • Only for official releases (not for RCs)
    • Go to GitHub Releases
    • Create release notes for the official version, it should auto-fill with merged PRs between the new official release and the last official release for you. Tweak the release notes if they don't mean anything to a user to make it make more sense.
    • Do not create the tag again - just the release notes

3. Post-Release Process

  1. Update Master Version:

    • Only after cutting the first RC (rc-1) - if this is not rc-1, skip this step
    • Go to GitHub Actions → Create a release workflow
    • Input the next SNAPSHOT version (e.g., 1.15.0-SNAPSHOT)
    • This is only done once per release cycle, right after the first RC is cut

  2. Branch Management:

    • After the official release, merge the release branch back to master via a single PR
    • This ensures master has all the release changes

Important Guidelines

Version Management

  • Never update versions manually - daprbot will PR version updates automatically
  • Never revert Javadoc PRs from daprbot - Java docs are automatically updated
  • The automation script is smart enough to determine the correct branch based on the version input

Branch Strategy

  • Always branch from master when using the GitHub Actions workflow
  • If a release branch already exists (from a previous RC), the automation will use the existing branch
  • For fresh releases, the automation creates the appropriate release branch

Documentation

  • Javadocs are automatically generated and updated - never revert these changes
  • The process is almost entirely automated
  • Release notes are NOT needed for RCs, only for official releases

Bugfixes and Hotfixes

  • If you need a bugfix in the latest release after the release branch has been cut:
    • Ensure the PR goes to master and the appropriate release branch
    • Cherry-pick commits as needed

Example Release Cycle

For a hypothetical release of version 1.20.0:

  1. First RC: Input 1.20.0-rc-1 → Creates release-1.20 branch
  2. Next Cycle Prep: Input 1.21.0-SNAPSHOT → Updates master for next development cycle
  3. Validation: Users test the RC
  4. Official Release: Input 1.20.0 → Uses existing release-1.20 branch (GHA input should have master bc the automation will choose the proper branch behind the scenes for us)

Troubleshooting

  • Build Failures: Check both the release branch and tag builds, worst case just delete the tag and retrigger CI to create a release
  • Version Conflicts: Ensure you're not manually updating versions
  • Documentation Issues: Never revert daprbot's Javadoc PRs. If daprbot's PR has issues, manually update the docs. Follow steps from this PR as a reference
  • Branch Issues: Always use master as the source branch in GitHub Actions

Everything below is left for historical purposes and is manual and outdated. The above process is latest and automated.

Release by GitHub Actions

  1. Latest build in master branch
    • maven pom version includes -SNAPSHOT suffix
    • Push snapshot package to nexus repository
  2. Release Candidate build in release-X.Y branch
    • maven pom version includes X.Y.Z-rc-W suffix
    • tagging vX.Y.Z-rc-W triggers build to publish X.Y.Z-rc-W to nexus snapshot repository
  3. Release build in release-X.Y branch
    • maven pom version MUST NOT have any suffix
    • tagging vX.Y.Z triggers build to publish X.Y.Z to nexus central repository

Manual Release steps

  1. Optionally, release a beta version.
# Set the two environment variables below.
export DAPR_JAVA_SDK_RELEASE="X.Y.Z-beta"
export DAPR_JAVA_SDK_RC_COUNT="1" #Incremented count like 1, 2, 3, etc..

export DAPR_JAVA_SDK_RELEASE_BRANCH="release-${DAPR_JAVA_SDK_RELEASE}"
export DAPR_JAVA_SDK_VERSION="${DAPR_JAVA_SDK_RELEASE}-${DAPR_JAVA_SDK_RC_COUNT}"

git checkout -b $DAPR_JAVA_SDK_RELEASE_BRANCH
git fetch upstream
git reset --hard upstream/master
./scripts/update_sdk_version.sh $DAPR_JAVA_SDK_VERSION

git commit -s -m "Release $DAPR_JAVA_SDK_VERSION" -a
git push upstream $DAPR_JAVA_SDK_RELEASE_BRANCH
git tag v$DAPR_JAVA_SDK_VERSION
git push upstream --tags

  1. Update the build.yaml and validate.yaml with the latest dapr runtime and CLI RCs.

  2. Create release-X.Y branch and push

# Set the three environment variables below.
export DAPR_JAVA_SDK_RELEASE="X.Y"
export DAPR_JAVA_SDK_PATCH_VERSION="0" #Incremented count like 0, 1, 2, 3, etc..
export DAPR_JAVA_SDK_RC_COUNT="1" #Incremented count like 1, 2, 3, etc..

export DAPR_JAVA_SDK_RELEASE_BRANCH="release-${DAPR_JAVA_SDK_RELEASE}"
export DAPR_JAVA_SDK_VERSION="${DAPR_JAVA_SDK_RELEASE}.${DAPR_JAVA_SDK_PATCH_VERSION}-rc-${DAPR_JAVA_SDK_RC_COUNT}"

git checkout -b $DAPR_JAVA_SDK_RELEASE_BRANCH
git fetch upstream
git reset --hard upstream/master
./scripts/update_sdk_version.sh $DAPR_JAVA_SDK_VERSION
git commit -s -m "Release $DAPR_JAVA_SDK_VERSION" -a
git push upstream $DAPR_JAVA_SDK_RELEASE_BRANCH
  1. Tag RC version (vX.Y.Z-rc-W)
git tag v$DAPR_JAVA_SDK_VERSION
git push upstream v$DAPR_JAVA_SDK_VERSION
  1. Prepare next release: Update version in master branch. Where N is Y+1.
# Set the two environment variables below.
export DAPR_JAVA_SDK_NEXT_RELEASE="X.N"
export DAPR_JAVA_SDK_NEXT_PATCH_VERSION="0" #Incremented count like 0, 1, 2, 3, etc..

export DAPR_JAVA_SDK_NEXT_VERSION="${DAPR_JAVA_SDK_NEXT_RELEASE}.${DAPR_JAVA_SDK_NEXT_PATCH_VERSION}-SNAPSHOT"

git checkout -b next-release-${DAPR_JAVA_SDK_NEXT_VERSION}
git fetch upstream
git reset --hard upstream/master
.github/scripts/update_sdk_version.sh $DAPR_JAVA_SDK_NEXT_VERSION

git commit -s -m "Upgrade the version to ${DAPR_JAVA_SDK_NEXT_VERSION}" -a
git push origin next-release-${DAPR_JAVA_SDK_NEXT_VERSION}

  1. Prepare next release: Create PR from next-release-* branch to master branch

  2. GitHub Actions will build and publish RC pkgs to Nexus OSS repository

  3. Test RC builds.

  4. In case of bugs, generate new RCs repeating steps 2 and 3.

Once the RC is good and we are OK to release, proceed.

  1. Remove RC suffix:
export DAPR_JAVA_SDK_VERSION="${DAPR_JAVA_SDK_RELEASE}.${DAPR_JAVA_SDK_PATCH_VERSION}"

git checkout $DAPR_JAVA_SDK_RELEASE_BRANCH
git fetch upstream
git reset --hard upstream/$DAPR_JAVA_SDK_RELEASE_BRANCH
.github/scripts/update_sdk_version.sh $DAPR_JAVA_SDK_VERSION
  1. Push the change to release-X.Y and release.
git commit -s -m "Upgrade version to $DAPR_JAVA_SDK_VERSION" -a
git push upstream $DAPR_JAVA_SDK_RELEASE_BRANCH
  1. Update README.md and Javadocs website
.github/scripts/update_docs.sh $DAPR_JAVA_SDK_VERSION
# MAKE SURE YOUR WORKING DIR IS CLEAN
git add -A
git commit -s -m "Generate updated javadocs for $DAPR_JAVA_SDK_VERSION" -a
git push upstream $DAPR_JAVA_SDK_RELEASE_BRANCH
  1. Release
git tag v${DAPR_JAVA_SDK_VERSION}
git push upstream v${DAPR_JAVA_SDK_VERSION}
  1. Update the live Javadocs website:
git checkout -b update_javadocs_$DAPR_JAVA_SDK_RELEASE_BRANCH
git reset --hard upstream/master
git cherry-pick $DAPR_JAVA_SDK_RELEASE_BRANCH
git push origin update_javadocs_$DAPR_JAVA_SDK_RELEASE_BRANCH
# Create PR into master and merge it.
  1. CI will release final build to central repository. Verify.

Version naming:

Naming convention is inspired by the one used in JUnit

  • Preview prior to a release candidate (optional): X.Y.Z-beta-W
  • Release candidate: X.Y.Z-rc-W
  • Release: X.Y.Z
  • Release branch: release-X.Y
  • Next release: X.Y.Z-SNAPSHOT
  • RC and beta counts start with 1.

Because the SDK version is in the pom.xml file, we DO NOT merge release back into master branch.

Clone this wiki locally