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)

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

Verified with multiple release versions:

• 8.18.7 → 8.18.8 ✅
• 9.0.5 → 9.0.6 ✅
• 10.1.0 → 10.1.1 ✅

Fixes #18637 (Goal 1)

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//pull/18634/files

Fixes #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]

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.

[v1v]

are we sure about this?

[isaacaflores2]

Hi @v1v , I have not tested this yet but based on our experience and reviewing the update-version code we need to provide the next version to bump to. Lets say the next release is for 9.2.1, this means we would provide 9.2.1 as an input into the patch release workflow. Currently the workflow attempts to update version.go to 9.2.1 which is a no-op, so as a work around we have been re-running the workflow by inputing vX.Y.Z+1 aka 9.2.2

[v1v]

Gotcha, if that's the case then all good.

For testing these scripts, I recommend using your forked repository, you can see some exmaples in the below comments or PRs:

• ci: use github app token #18865 (comment)
• ci: update changelog release automation #16358 (comment)
• ci(release minor): add tag::list entry for minor release in the changelog #14025