Fix auto-detection of latest package version

[stracker-phil]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Bug fix

What is the current behavior? (You can also link to an open issue here)

The automatically determined PACKAGE_VERSION defaulted to the most recently created git tag, regardless of whether that tag represented an actual release version or something else (e.g. arbitrary non-semver tags such as archive/qa-legacy-ui-tests).

This caused two problems downstream, where PACKAGE_VERSION is consumed:

• Build breaks on tags containing slashes. The "Prepare WordPress Plugin" and "Prepare WordPress Theme" steps interpolate PACKAGE_VERSION into a sed expression that uses / as its delimiter; a slash in the tag breaks the substitution with an error.
• Invalid versions without a slash silently land in project files. Non-semver tags get written into package.json (via npm version, which rejects them) and composer.json (via jq, which accepts any string), corrupting the build artifact.

What is the new behavior (if this is a feature change)?

The workflow now fetches the tag name of an actual GitHub Release via gh release list, so only published releases are considered.

Assumption: A release tag represents a valid semantic version and never contains slashes, e.g.

• 4.0.3
• 4.0.3-alpha-2026-05-06
• v2.17.0

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

The "0.0.0" fallback already existed previously, but it now triggers in more cases: any repository that has tags but no published GitHub Release will fall back to "0.0.0" instead of picking up a tag.

This will not block the build, but it will insert a "0.0.0"-based version string into project files in the following steps:

• Prepare WordPress Plugin
• Prepare WordPress Theme
• Update version in package.json
• Update version in composer.json

Other information

Repositories that previously relied on tags being picked up without ever cutting a GitHub Release should publish a Release to keep getting a meaningful version prefix.

npm version requirements

The workflow constructs PACKAGE_VERSION and validates it against semver vianpm version in the "Update version in package.json" step. This means, the LATEST_RELEASE string itself must match the following pattern to pass this check:

[v]MAJOR.MINOR.PATCH[-IDENTIFIER]

Valid samples:

• 1.2.3
• v1.2.3
• 1.2.3-alpha
• 1.2.3-feature.1
• 1.2.3-2026-05-21

Invalid samples:

• 1.2 → missing PATCH
• 1.2.3.4 → too many segments
• 1.2.3- → empty identifier
• v.1.2.3 → dot after v
• a.b.c → non-numeric segments

[tyrann0us]

Please update the documentation, which still states that we are fetching the last tag from the repository, whereas it is now the last release.

[Biont]

Thanks for this. I believe this was the correct approach all the time. I was "emotionally" in favor of a git-only (no gh cli) approach when I built this, but given that we are in the context of GitHub Actions, there's just no reason not to commit to their tooling.

IMO we can remove the fallback as per https://github.com/inpsyde/reusable-workflows/pull/245/changes#r3196373868 - then we are golden

[tyrann0us]

Thank you for working on this! LGTM