Adopt RFC 0018 release branch naming (release-X.Y)

.github/actions/create-release-branch/action.yaml

@@ -25,7 +25,7 @@ runs:
         INPUT_VERSION: ${{ inputs.version }}
         INPUT_PUSH: ${{ inputs.push }}
       run: |
-        base_branch=release-v$(echo "$INPUT_VERSION" | sed 's/[+-].*//; s/\.[0-9]*$//')
+        base_branch=release-$(echo "$INPUT_VERSION" | sed 's/[+-].*//; s/\.[0-9]*$//')
         echo "branch-name=$base_branch" >> "$GITHUB_OUTPUT"
 
         if git ls-remote --exit-code --heads origin "$base_branch"; then

.github/workflows/automated-release.yaml

@@ -42,7 +42,7 @@ jobs:
           author: ${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com>
           signoff: true
           base: ${{ steps.prepare-branch.outputs.branch-name }}
-          branch: release-v${{ github.event.inputs.version }}
+          branch: release-${{ github.event.inputs.version }}
           delete-branch: true
           title: "[Release] Developer Portal Controller v${{ github.event.inputs.version }}"
           body: |

.github/workflows/release.yaml

@@ -6,6 +6,7 @@ on:
       - closed
     branches:
       - 'release-v[0-9]+.[0-9]+'
+      - 'release-[0-9]+.[0-9]+'
   workflow_dispatch: {}
 
 jobs:

RELEASE.md

@@ -9,17 +9,17 @@ The version is defined in the `Makefile`:
 VERSION ?= X.Y.Z
 ```
 
-**Important:** The `main` branch always has `VERSION ?= 0.0.0` as a placeholder. The actual version is only set on release branches (e.g., `release-v0.1`). This follows the same pattern as [kuadrant-operator](https://github.com/Kuadrant/kuadrant-operator). When building release images, the version is read from the release branch where the automated workflow updated it.
+**Important:** The `main` branch always has `VERSION ?= 0.0.0` as a placeholder. The actual version is only set on release branches (e.g., `release-0.1`). This follows the same pattern as [kuadrant-operator](https://github.com/Kuadrant/kuadrant-operator). When building release images, the version is read from the release branch where the automated workflow updated it.
 
 ## Automated Workflow (Recommended)
 
 _**IMPORTANT:**_
-For RC2+ or patch releases, set `gitRef` to the existing release branch (e.g., `release-v0.1`), not `main`.
+For RC2+ or patch releases, set `gitRef` to the existing release branch (e.g., `release-0.1`), not `main`.
 The workflow picks up all history from the specified gitRef - cherry-pick any required fixes to the release branch before triggering the workflow.
 
 ### Notes
 * The automated workflow is best suited for RC1 of a new point release from `main`.
-* For patch releases (e.g., 0.1.1): Cherry-pick only the bug fix to the release branch, then run the workflow with `gitRef: release-v0.1`.
+* For patch releases (e.g., 0.1.1): Cherry-pick only the bug fix to the release branch, then run the workflow with `gitRef: release-0.1`.
 * It's not possible to cherry-pick commits within the workflow - it will include all history from the gitRef.
 
 ### Steps
@@ -48,14 +48,14 @@ To release a patch (e.g., `0.1.1` after `0.1.0` with a bug fix from `main`):
 
 1. **Cherry-pick the fix to the release branch**:
    ```bash
-   git checkout release-v0.1
-   git pull origin release-v0.1
+   git checkout release-0.1
+   git pull origin release-0.1
    git cherry-pick <commit-sha>    # Only the bug fix, not new features
-   git push origin release-v0.1
+   git push origin release-0.1
    ```
 
 2. **Run the Automated Release workflow**:
-   - **gitRef**: `release-v0.1` (the release branch, NOT main)
+   - **gitRef**: `release-0.1` (the release branch, NOT main)
    - **version**: `0.1.1`
 
 3. **Review and merge the PR**, then the release will be created automatically.