THIS IS A DRAFT

Current Release Workflow

The current release workflow is optimized for feature releases from the main branch. When approaching a release, the current state of the main branch is merged to the release/1.x branch. On that branch the release is tested and when needed, fixes are done on that branch. Also, certain commits can be cherry-picked from the main branch to the release branch. After the release, the changes on the release/1.x branch are merged back to main.

Since merging off the main state for release 1.0 already a lot of commits have been added to the main branch. The majority of these commits are dependency upgrades and a few bug fixes. Most of them should go to a patch release 1.0.1 (and later 1.0.2 etc.).

The requirement is to extend the build workflows that patch releases can be done with minimal effort in order to bring them in short time.

What needs to be done?

Labeling changes to backport

Issues and pull requests that are eligable for a patch release have to be marked. Therefore the label backport:patch-release exists. In a first step, assigning the label is to be done manually.

Determine patch version

The patch version can be determined from the /pom.xml in branch release/1.x.

The patch version is the project version with suffix -SNAPSHOT removed. Example: Currently the pom.xml contains 1.0.1-SNAPSHOT, i.e. the patch version will be 1.0.1.

Patch release branch

The target branch for PRs is release/<PATCH_VERSION> (e.g. release/1.0.1)
If this branch does not exist on remote:

• Create from release/1.x (explicit commit reference: tip of release/1.x)
• Push the branch to remote. The automation must use a Bot PAT with repo write permission or use GITHUB_TOKEN if allowed.
• The workflow creates it, according permission is required to the workflow

Patch Release Workflow

For each PR merged into main that has label backport:patch-release, create a backport PR to release/<PATCH_VERSION>. Use the commits that are in the PR merge (use PR commits list; for squash merges use the single commit created by the merge).

The backport PR is also created, when the label backport:patch-release is assigned to an already closed PR.

The PR uses the following rules:

• Title: release/backports/-PR-
• Body:
  • Backport-of: #
  • Cherry-picked commits: - (original author , if not dependabot)
• Commit message lines: "Backport-of: #" and "Original-commit: (author)" (author only when not dependabot).

Integration Build Workflow

The Integration Build workflow has to be executed on the patch release branch for the PR.

The workflow should be triggered nightly for the release/1.x branch to perform a full integration build and release. Since scheduled builds can only be executed for the main branch, a small workflow is needed that runs on main and triggers the Integration Build for branch release/1.x nightly.

✅ DONE

Changes to JReleaser

The JReleaser creates only a single early-access release. It is now required that multiple preliminary releases exist. The patch release shall become release (< PATCH_VERSION >-SNAPSHOT).

✅ DONE

Nightly auto-merge

A workflow that on nightly schedule at 5:15 shall merge open PRs labeled with backport:patch-release that have successful checks.

Result