Fix codefreeze to check PR target branch correctly

Signed-off-by: Andrew Leonard <anleonar@redhat.com>

.github/workflows/code-freeze.yml

@@ -1,5 +1,5 @@
 # ********************************************************************************
-# Copyright (c) 2023 Contributors to the Eclipse Foundation
+# Copyright (c) 2023, 2024 Contributors to the Eclipse Foundation
 #
 # See the NOTICE file(s) with this work for additional
 # information regarding copyright ownership.
@@ -16,7 +16,8 @@ name: Code Freeze Bot
 # Controls when the workflow will run
 on:
   pull_request_target:
-    branches: [ "v[0-9]+.[0-9]+.[0-9]+" ]
+    branches:
+      - '*'
   issue_comment:
     types: [created]
 
@@ -25,6 +26,15 @@ permissions:
   pull-requests: write
 
 jobs:
-  codefreeze:
+  # Check if the pull request target branch matches the required branch-regex?
+  codefreeze_branch_check:
+    uses: adoptium/.github/.github/workflows/code-freeze-regex-branch.yml@main
+    with:
+      branch-regex: "^v[0-9]+.[0-9]+.[0-9]+$"
+
+  # Code freeze if branch-regex matches
+  codefreeze_if_branch_match:
+    needs: codefreeze_branch_check
     uses: adoptium/.github/.github/workflows/code-freeze.yml@main
+    if: (github.event_name == 'pull_request_target' || (github.event_name == 'issue_comment' && github.event.issue.pull_request)) && needs.codefreeze_branch_check.outputs.regex-matches == 'true'
     secrets: inherit

RELEASING.md

@@ -54,7 +54,7 @@ Create release branch in the format `vYYYY.MM.NN` on each of the following repos
 - ci-jenkins-pipelines <https://github.com/adoptium/ci-jenkins-pipelines>
 - jenkins-helper <https://github.com/adoptium/jenkins-helper>
 
-These branches should be named according to the following format (vYYYY.MM+NN) ,e.g v2023.03+01 , whereby the final element is an incremental counter appended to the year and month of the release.
+These branches should be named according to the following format (vYYYY.MM.NN) ,e.g v2023.03.01 , whereby the final element is an incremental counter appended to the year and month of the release.
 
 If anything needs to be merged into the new branch, it should typically be merged into master, then a `git cherry-pick` operation should be done to create a new PR against the release branch. This can typically be merged without further approval.