Fix patch release workflow to use NEXT_RELEASE for version updates

[Copilot]

Problem

The patch-release target in release.mk had an inconsistency that caused confusion during patch releases. When releasing version 8.18.7, the workflow would:

• Create a branch named update-8.18.8 (using NEXT_RELEASE)
• But update version files to 8.18.7 (using RELEASE_VERSION)
• Generate commit message: "update versions to 8.18.7"
• Create PR with title: "8.18.7: update versions"

This was confusing because the branch name suggested updating to 8.18.8, but the actual version updates pointed to 8.18.7.

Solution

Updated the patch-release target to consistently use NEXT_RELEASE (which is automatically calculated as RELEASE_VERSION + 1) throughout the workflow:

1. Changed update-version to use $(NEXT_RELEASE) instead of $(RELEASE_VERSION)
2. Updated commit message to reference $(NEXT_RELEASE)
3. Updated PR title to reference $(NEXT_RELEASE)
4. Change patch release branch name from 'update-' to 'bump-to-next-patch-'

Result

Now when releasing version 8.18.7, the workflow correctly:

• Creates branch: update-8.18.8
• Updates version files to: 8.18.8
• Generates commit message: "8.18: update versions to 8.18.8"
• Creates PR with title: "8.18.8: update versions"

All references are now consistent! This eliminates the need for manual calculation and makes the workflow's intent clear: preparing the repository for the next version after the release.

Testing

Tested on forked repository against the branches 8.19 and 9.2

• Set up github token with: export GITHUB_TOKEN=<token>
• Cherry-pick release.mk changes to each branch

git cherry-pick 77f08ef2
git cherry-pick 274b0067

• Push changes and then run the make patch-release for each version

Patch 8.19

make patch-release RELEASE_BRANCH=8.19 RELEASE_VERSION=8.19.7 NEXT_RELEASE=8.19.8 RELEASE_TYPE=patch PROJECT_OWNER=isaacaflores2

-> Created PR: https://github.com/isaacaflores2/apm-server/pull/1

Patch 9.1

make patch-release RELEASE_BRANCH=9.1 RELEASE_VERSION=9.1.7 NEXT_RELEASE=9.1.8 RELEASE_TYPE=patch PROJECT_OWNER=isaacaflores2

-> Created PR: https://github.com/isaacaflores2/apm-server/pull/4 -> Created release notes PR: https://github.com/isaacaflores2/apm-server/pull/5

Patch 9.2

make patch-release RELEASE_BRANCH=9.2 RELEASE_VERSION=9.2.1 NEXT_RELEASE=9.2.2 RELEASE_TYPE=patch PROJECT_OWNER=isaacaflores2

-> Created PR: https://github.com/isaacaflores2/apm-server/pull/2

• Note: I forgot to push the release.mk changes before running patch-release so this PR includes changes to that file -> Created release notes PR: https://github.com/isaacaflores2/apm-server/pull/3

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Improve the patch release workflow</issue_title> <issue_description>

The current patch release workflow is a bit confusing and generally results in a developer making manual changes versus relying on the automation.

Goals

1. Update the release workflow to avoid having to provide X.Y.Z+1 i.e for the 8.18.7 we should not have to pass 8.18.8. This is most likely due to update-version expecting the next release version here. A possible solution is listed below:
   • We already calculate X.Y.Z+1 here under the NEXT_RELEASE var: https://github.com/elastic/apm-server/blob/main/release.mk#L47
   • Example assuming the release is for 8.18.7 (env var RELEASE_VERISON)
     • This var is used to create the new branch update-8.18.8. But we pass in the RELEASE_VERISON to update-version https://github.com/elastic/apm-server/blob/main/release.mk#L47
     • So this should be updated to : $(MAKE) update-version VERSION=$(NEXT_RELEASE) ?
2. The automation creates a misleading branch. Example for the 8.18.7 release, the automation will create a branch update-8.18.8 to change all necessary files to the next version 8.18.8. The branch name implies the we are updating 8.18.8 versus changing files to bump to 8.18.8. This should help avoid any confusion on the purpose of the branch, especially for anyone not familiar with the details of the release workflows.
3. Update release documentation to clarify instructions</issue_description>

<agent_instructions>Lets focus on goal 1. Update the release.mk fail to avoid having to provide X.Y.Z+1. Review the provided context in the issue description for more details</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@isaacaflores2 This PR attempts to clarify some instructions for 8.x patch releases: https://github.com/elastic/apm-server/pull/18634/files

Implements elastic/apm-server#18853

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[mergify[bot]]

This pull request does not have a backport label. Could you fix it @Copilot? 🙏 To fixup this pull request, you need to add the backport labels for the needed branches, such as:

• backport-7.17 is the label to automatically backport to the 7.17 branch.
• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
• backport-9./d is the label to automatically backport to the 9./d branch. /d is the digit.
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[isaacaflores2]

I tested the upcoming patch releases on my fork (details) in the description. You can see the PRs created here: https://github.com/isaacaflores2/apm-server/pulls.

The PRs include multiple backup files (.bck). I am not sure why this is happening but I do not think it is release to any of my changes. @v1v please let me know if you disagree or know why the backup files are being created.

@carsonip If there are no concerns with this PR and you would like to use the updated patch-release. Feel free to merge this PR and backport. Otherwise I can make any other changes, so the team can you this on the subsequent patch release(s).

[v1v]

The PRs include multiple backup files (.bck). I am not sure why this is happening but I do not think it is release to any of my changes. @v1v please let me know if you disagree or know why the backup files are being created.

I bet, copilot created them, I've seen that behaviour in the past

[carsonip]

@carsonip If there are no concerns with this PR and you would like to use the updated patch-release. Feel free to merge this PR and backport. Otherwise I can make any other changes, so the team can you this on the subsequent patch release(s).

I didn't merge this PR. Used the old workflow. It worked fine.

TBH my only complaint about the process is just that the github workflow textbox description around FF version was confusing. If we clarify that, we could skip making any changes to the code.