fix: Backport changelog version environment

Pass validated maintenance release versions through the workflow environment while retaining the 11.6.1 runtime reference.

(cherry picked from commit f10613e)

Author: ErikUggeldahl

.github/scripts/release/.release-it.json

@@ -2,7 +2,7 @@
   "git": {
     "commitMessage": "chore: release v${version}",
     "tagName": "${version}",
-    "changelog": "npx auto-changelog --stdout --commit-limit false --unreleased --latest-version ${latestVersion} --template https://raw.githubusercontent.com/release-it/release-it/master/templates/changelog-compact.hbs"
+    "changelog": "npx auto-changelog --stdout --commit-limit false --unreleased --latest-version \"$CURRENT_VERSION\" --template https://raw.githubusercontent.com/release-it/release-it/master/templates/changelog-compact.hbs"
   },
   "github": {
     "release": true,
@@ -26,7 +26,7 @@
   },
   "hooks": {
     "after:bump": [
-      "npx auto-changelog --latest-version ${version} -o ../../../CHANGELOG.md --hide-empty-releases",
+      "npx auto-changelog --latest-version \"$TARGET_VERSION\" -o ../../../CHANGELOG.md --hide-empty-releases",
       "git add ../../../CHANGELOG.md",
       "git add ../../../VERSION"
     ]

.github/scripts/release/README.md

@@ -45,38 +45,43 @@ For `TARGET_VERSION=12.0.1`, this effectively runs `release-it 12.0.1 --ci`. The
 
 ## Current and Target Versions
 
-The `.release-it.json` configuration uses two variables supplied by `release-it`:
+The release step passes two workflow outputs through its environment:
 
-- `${latestVersion}` is the version read from the Android `VERSION` file before it is bumped. It
-  is the current completed release, such as `12.0.0`.
-- `${version}` is the target version passed to `release-it`, such as `12.0.1`.
+- `$CURRENT_VERSION` is the version read from the Android `VERSION` file before it is bumped. It is
+  the current completed release, such as `12.0.0`.
+- `$TARGET_VERSION` is the version calculated by the workflow and passed to `release-it`, such as
+  `12.0.1`.
+
+These are workflow environment variables rather than release-it template variables. Release-it
+generates `git.changelog` before it adds its `latestVersion` and `version` values to the global
+template context, so those template variables are not available when this command is rendered.
 
 The `@release-it/bumper` plugin's `in` configuration makes the Android `VERSION` file the source
-of `latestVersion`. Its `out` configuration writes `version` back to that file during the bump. The
-plugin does not choose the target version; the workflow passes that version as the positional
-argument. Without this plugin, release-it would normally read the current version from
-`package.json` or the latest Git tag and persist the target through its corresponding version
-mechanism.
+of release-it's current version. Its `out` configuration writes release-it's target version back to
+that file during the bump. The plugin does not choose the target version; the workflow passes that
+version as the positional argument. Without this plugin, release-it would normally read the current
+version from `package.json` or the latest Git tag and persist the target through its corresponding
+version mechanism.
 
 ## Release Notes and `CHANGELOG.md`
 
 The two `auto-changelog` commands serve different phases of the release:
 
 1. `git.changelog` runs before the bump and writes release-note text to standard output. The
-   `--unreleased --latest-version ${latestVersion}` arguments mean "collect changes after the
-   selected branch's current completed release through `HEAD`." Pinning `latestVersion` prevents a
+   `--unreleased --latest-version $CURRENT_VERSION` arguments mean "collect changes after the
+   selected branch's current completed release through `HEAD`." Pinning `CURRENT_VERSION` prevents a
    newer tag from another release line, such as `12.1.0`, from becoming the boundary for a
    `12.0.1` maintenance release.
-2. The `after:bump` hook regenerates and stages `CHANGELOG.md`. At this point `${version}` is the
-   new target, so `--latest-version ${version}` assigns those formerly unreleased changes to the
-   new `12.0.1` section.
+2. The `after:bump` hook regenerates and stages `CHANGELOG.md`. At this point `$TARGET_VERSION` is
+   the new target, so `--latest-version $TARGET_VERSION` assigns those formerly unreleased changes
+   to the new `12.0.1` section.
 
 For a `12.0.1` maintenance release, the lifecycle is therefore:
 
 ```text
 VERSION contains 12.0.0
-    → latestVersion = 12.0.0
+    → CURRENT_VERSION = 12.0.0
     → collect commits after 12.0.0 as unreleased release notes
-    → bump to version = 12.0.1
+    → bump to TARGET_VERSION = 12.0.1
     → write those commits under 12.0.1 in CHANGELOG.md
 ```

.github/workflows/release.yml

@@ -157,12 +157,13 @@ jobs:
           git config --local user.email 'hello@rive.app'
           git config --local user.name ${{ github.actor }}
 
-      # The validation step writes target_version to GITHUB_OUTPUT. GitHub resolves the expression
-      # below and supplies it to release-it as the TARGET_VERSION environment variable.
+      # The validation step writes both versions to GITHUB_OUTPUT. GitHub resolves the expressions
+      # below and supplies them to release-it as environment variables.
       - name: ${{ inputs.bump }} release - Bump version number, update changelog, push and tag
         run: npm run release -- "$TARGET_VERSION" --ci
         working-directory: ./.github/scripts/release
         env:
+          CURRENT_VERSION: ${{ steps.release.outputs.current_version }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           TARGET_VERSION: ${{ steps.release.outputs.target_version }}