shakapacker 9.6.0.rc.1 → 9.6.0.rc.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 68ba8fdde7f793bee53354a639cf21695963ff564e3478de1e19711f9e71704d
-  data.tar.gz: f5baa408e07f17e89cb0ba19abe652a4eeba151400b5014b4381156221e25811
+  metadata.gz: f8de376ed8bf26aa80f043c1b4f1edfe9fe14e76b8b5db9d4d4bdfc6fc1b0c62
+  data.tar.gz: 84db935f44746cc5ec67a1e71018bab24d1a17c2be17a27a4d6d894e35e4e106
 SHA512:
-  metadata.gz: 3845c0fd8e02339a077dd2a385bc2ed32905e62f56f786177c5761ddca3fab1b521bb92aeb1469458657cb139273137079a33e1ebbffba9574cf1e192e56fac2
-  data.tar.gz: 81d6113206160b9184bc1a0016cbe52d0c0ee565cd951da3b613ae99dd58ea83279d6ee60bfa6be8f14a2d524900941ed7568c8169ba2d855a9734c856260cc3
+  metadata.gz: c9b75f026df4c043286fe9d068651de5c67eecd2c34a6946a6d708498d6c9cd032db716805126eb280ef72ef828582391d0579f304d30ccf736fd6d0d3ea6456
+  data.tar.gz: 5574ca0d5f1992980e8f2cb615c76fb0934201493d0994fcef5a6824040ba3eb6a01d4aae087fc2941b3fa52529eb6f6ec71e1b4230f9c44c6379d4b0fdb141e

data/.claude/commands/update-changelog.md

@@ -2,6 +2,68 @@
 
 You are helping to add an entry to the CHANGELOG.md file for the Shakapacker project.
 
+## Arguments
+
+This command accepts an optional argument: `$ARGUMENTS`
+
+- **No argument** (`/update-changelog`): Add entries to `[Unreleased]` without stamping a version header. Use this during development.
+- **`release`** (`/update-changelog release`): Add entries and stamp a version header. Auto-compute the next version based on changes (breaking → major, added features → minor, fixes → patch). Then `rake create_release` (with no args) will pick up this version automatically.
+- **`rc`** (`/update-changelog rc`): Same as `release`, but stamps an RC prerelease version (e.g., `v9.7.0-rc.0`). Auto-increments the RC index if prior RCs exist for the same base version.
+- **`beta`** (`/update-changelog beta`): Same as `rc`, but stamps a beta prerelease version (e.g., `v9.7.0-beta.0`).
+
+## When to Use This
+
+This command serves three use cases at different points in the release lifecycle:
+
+**During development** — Add entries to `[Unreleased]` as PRs merge:
+
+- Run `/update-changelog` to find merged PRs missing from the changelog
+- Entries accumulate under `## [Unreleased]`
+
+**Before a release** — Stamp a version header and prepare for release:
+
+- Run `/update-changelog release` (or `rc` or `beta`) to add entries AND stamp the version header
+- The version is auto-computed from changelog content (see "Auto-Computing the Next Version" below)
+- Commit and push CHANGELOG.md
+- Then run `rake create_release` (no args needed — it reads the version from CHANGELOG.md)
+- The release task automatically creates a GitHub release from the changelog section
+
+**After a release you forgot to update the changelog for** — Catch-up mode:
+
+- The command can retroactively find commits between tags and add missing entries
+- Ask the user whether to stamp a version header or add to `[Unreleased]`
+
+### Why changelog comes BEFORE the release
+
+- `create_release` automatically creates a GitHub release if a changelog section exists — no separate `sync_github_release` step needed
+- The release task warns if no changelog section is found for the target version
+- A premature version header (if release fails) is harmless — you'll release eventually
+- A missing changelog after release means GitHub release must be created manually
+
+## Auto-Computing the Next Version
+
+When stamping a version header (`release`, `rc`, or `beta`), compute the next version as follows:
+
+1. **Find the latest stable version tag** using semver sort:
+
+   ```bash
+   git tag -l 'v*' --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -1
+   ```
+
+2. **Determine bump type from changelog content**:
+   - If changes include `### Breaking Changes` or `### ⚠️ Breaking Changes` → **major** bump
+   - If changes include `### Added` or `### New Features` → **minor** bump
+   - If changes only include `### Fixed`, `### Security`, `### Improved`, `### Changed`, `### Deprecated` → **patch** bump
+
+3. **Compute the version**:
+   - For `release`: Apply the bump to the latest stable tag (e.g., `9.5.0` + minor → `9.6.0`)
+   - For `rc`: Apply the bump, then find the next RC index (e.g., if `v9.6.0-rc.0` tag exists → `v9.6.0-rc.1`)
+   - For `beta`: Same as RC but with beta suffix
+
+4. **Verify**: Check that the computed version is newer than ALL existing tags (stable and prerelease). If not, ask the user what to do.
+
+5. **Show the computed version to the user** and ask for confirmation before stamping the header.
+
 ## Critical Requirements
 
 1. **User-visible changes only**: Only add changelog entries for user-visible changes:
@@ -74,6 +136,21 @@ Entries should be organized under these section headings. The project uses both
 
 **Only include section headings that have entries.**
 
+### Version Header Format
+
+**Stable releases**: `## [v9.6.0] - March 7, 2026`
+
+**Prerelease versions** (RC and beta): Use npm semver format with dashes, NOT RubyGems dot format:
+
+- Correct: `## [v9.6.0-rc.1]` (npm semver — this is what `sync_github_release` expects)
+- Wrong: `## [v9.6.0.rc.1]` (RubyGems format — do NOT use this in CHANGELOG.md headers)
+
+This matters because the release rake tasks convert between formats:
+
+- Git tags use npm format: `v9.6.0-rc.1`
+- Gem versions use RubyGems format: `9.6.0.rc.1`
+- CHANGELOG.md headers must match git tag format: `## [v9.6.0-rc.1]`
+
 ### Version Management
 
 After adding entries, use the rake task to manage version headers:
@@ -110,16 +187,17 @@ When a new version is released:
 ### For Regular Changelog Updates
 
 1. **ALWAYS fetch latest changes first**:
-   - **CRITICAL**: Run `git fetch origin main` to ensure you have the latest commits
+   - **CRITICAL**: Run `git fetch origin main --tags` to ensure you have the latest commits AND tags
    - The workspace may be behind origin/main, causing you to miss recently merged PRs
    - After fetching, use `origin/main` for all comparisons, NOT local `main` branch
 
 2. **Determine the correct version tag to compare against**:
-   - First, check the tag dates: `git log --tags --simplify-by-decoration --pretty="format:%ai %d" | head -10`
-   - Find the latest version tag and its date
-   - Compare origin/main branch date to the tag date
-   - If the tag is NEWER than origin/main, it means the branch needs to be updated to include the tag's commits
-   - **CRITICAL**: Always use `git log TAG..BRANCH` to find commits that are in the tag but not in the branch, as the tag may be ahead
+   - List all version tags sorted by semver: `git tag -l 'v*' --sort=-v:refname | head -10`
+   - This correctly sorts RC/beta tags (e.g., `v9.6.0-rc.1` sorts after `v9.6.0-rc.0` and before `v9.6.0`)
+   - The latest tag may be a stable release, RC, or beta — handle all cases
+   - Compare origin/main branch date to the tag date using: `git log -1 --format="%ai" origin/main` and `git log -1 --format="%ai" <tag>`
+   - If the tag is NEWER than origin/main, the branch needs updating to include the tag's commits
+   - **CRITICAL**: Always use `git log TAG..BRANCH` to find commits in the branch but not the tag, AND `git log BRANCH..TAG` to check if the tag is ahead
 
 3. **Check commits and version boundaries**:
    - **IMPORTANT**: Use `origin/main` in all commands below, not local `main`
@@ -162,37 +240,44 @@ When a new version is released:
 
 10. **Show the user** the added or moved entries and explain what was done.
 
-### For Beta to Non-Beta Version Release
+### For Prerelease Versions (RC and Beta)
 
-When releasing from beta to a stable version (e.g., v9.1.0-beta.3 → v9.1.0):
+When the user passes `rc` or `beta` as an argument (or when creating a prerelease section manually):
 
-1. **Remove all beta version labels** from the changelog:
-   - Change `## [v9.1.0-beta.1]`, `## [v9.1.0-beta.2]`, etc. to a single `## [v9.1.0]` section
-   - Combine all beta entries into the stable release section
+1. **Find the latest tag** (stable or prerelease) using semver sort:
 
-2. **Consolidate duplicate entries**:
-   - If bug fixes or changes were made to features introduced in earlier betas, keep only the final state
-   - Remove redundant changelog entries for fixes to beta features
-   - Keep the most recent/accurate description of each change
+   ```bash
+   git tag -l 'v*' --sort=-v:refname | head -10
+   ```
 
-3. **Update version diff links** at the bottom to point to the stable version
+2. **Auto-compute the next prerelease version** using the process in "Auto-Computing the Next Version" above.
 
-### For New Beta Version Release
+3. **Use npm semver format** for the version header:
+   - RC: `## [v9.6.0-rc.1]`
+   - Beta: `## [v9.6.0-beta.2]`
 
-When creating a new beta version, ask the user which approach to take:
+4. **Always collapse prior prereleases into the current prerelease** (this is the default behavior):
+   - Combine all prior prerelease changelog entries into the new prerelease version section
+   - Remove previous prerelease version sections (e.g., remove `## [v9.6.0-rc.0]` when creating `## [v9.6.0-rc.1]`)
+   - Add any new user-visible changes from commits since the last prerelease
+   - Update version diff links to point from the last stable version to the new prerelease
+   - This keeps the changelog clean with a single prerelease section that accumulates all changes since the last stable release
 
-**Option 1: Process changes since last beta**
+### For Prerelease to Stable Version Release
 
-- Only add entries for commits since the previous beta version
-- Maintains detailed history of what changed in each beta
+When releasing from prerelease to a stable version (e.g., v9.6.0-rc.1 → v9.6.0):
 
-**Option 2: Collapse all prior betas into current beta**
+1. **Remove all prerelease version labels** from the changelog:
+   - Change `## [v9.6.0-rc.0]`, `## [v9.6.0-rc.1]`, etc. to a single `## [v9.6.0]` section
+   - Also handle beta versions: `## [v9.6.0-beta.1]` etc.
+   - Combine all prerelease entries into the stable release section
 
-- Combine all beta changelog entries into the new beta version
-- Removes previous beta version sections
-- Cleaner changelog with less version noise
+2. **Consolidate duplicate entries**:
+   - If bug fixes or changes were made to features introduced in earlier prereleases, keep only the final state
+   - Remove redundant changelog entries for fixes to prerelease features
+   - Keep the most recent/accurate description of each change
 
-After the user chooses, proceed with that approach.
+3. **Update version diff links** at the bottom to point to the stable version
 
 ## Examples
 

data/CHANGELOG.md

@@ -11,7 +11,7 @@
 
 Changes since the last non-beta release.
 
-## [v9.6.0-rc.0] - March 5, 2026
+## [v9.6.0-rc.2] - March 7, 2026
 
 ### Security
 
@@ -72,7 +72,7 @@ Changes since the last non-beta release.
 - **Improved error message when manifest is empty or missing**. [PR #872](https://github.com/shakacode/shakapacker/pull/872) by [justin808](https://github.com/justin808). When the bundler is still compiling (empty manifest) or hasn't run yet (missing manifest file), users now see clear, actionable error messages instead of the generic 7-point checklist.
 - **Fixed NODE_ENV=test causing DefinePlugin warnings**. [PR #870](https://github.com/shakacode/shakapacker/pull/870) by [justin808](https://github.com/justin808). When RAILS_ENV=test, Shakapacker now sets NODE_ENV=development instead of NODE_ENV=test. This prevents webpack/rspack DefinePlugin conflicts since these bundlers only recognize "development" and "production" as valid NODE_ENV values.
 - **Fixed `--json` flag output being corrupted by log messages**. [PR #869](https://github.com/shakacode/shakapacker/pull/869) by [justin808](https://github.com/justin808). When `--json` is in the command arguments, `[Shakapacker]` log messages are now written to stderr instead of stdout, keeping stdout clean for valid JSON output. This allows `bin/shakapacker --profile --json` to be piped to tools like `webpack-bundle-analyzer`. Normal (non-JSON) usage is unchanged. Resolves [#868](https://github.com/shakacode/shakapacker/issues/868).
-- **Require explicit truthy values for `SKIP` and `FORCE` installer env vars**. [PR #926](https://github.com/shakacode/shakapacker/pull/926) by [justin808](https://github.com/justin808). Previously, any set value (including `"false"` or `"0"`) would activate skip/force mode. Now only explicit truthy values (`true`, `1`, `yes`, case-insensitive) are recognized. This behavior change may require CI/scripts that relied on `FORCE=<any non-empty value>` to switch to `FORCE=true`.
+- **Require explicit truthy values for all installer env vars**. [PR #926](https://github.com/shakacode/shakapacker/pull/926), [PR #943](https://github.com/shakacode/shakapacker/pull/943) by [justin808](https://github.com/justin808). Previously, any set value (including `"false"` or `"0"`) would activate these flags. Now only explicit truthy values (`true`, `1`, `yes`, case-insensitive) are recognized for `SKIP`, `FORCE`, `USE_BABEL_PACKAGES`, `SHAKAPACKER_USE_TYPESCRIPT`, and `SKIP_COMMON_LOADERS`. This behavior change may require CI/scripts that relied on arbitrary non-empty values to switch to recognized truthy values like `true`.
 
 ### Documentation
 
@@ -868,8 +868,8 @@ Note: [Rubygem is 6.3.0.pre.rc.1](https://rubygems.org/gems/shakapacker/versions
 
 See [CHANGELOG.md in rails/webpacker (up to v5.4.3)](https://github.com/rails/webpacker/blob/master/CHANGELOG.md)
 
-[Unreleased]: https://github.com/shakacode/shakapacker/compare/v9.6.0-rc.0...main
-[v9.6.0-rc.0]: https://github.com/shakacode/shakapacker/compare/v9.5.0...v9.6.0-rc.0
+[Unreleased]: https://github.com/shakacode/shakapacker/compare/v9.6.0-rc.2...main
+[v9.6.0-rc.2]: https://github.com/shakacode/shakapacker/compare/v9.5.0...v9.6.0-rc.2
 [v9.5.0]: https://github.com/shakacode/shakapacker/compare/v9.4.0...v9.5.0
 [v9.4.0]: https://github.com/shakacode/shakapacker/compare/v9.3.4...v9.4.0
 [v9.3.4]: https://github.com/shakacode/shakapacker/compare/v9.3.3...v9.3.4

data/docs/releasing.md

@@ -9,7 +9,7 @@ This guide is for Shakapacker maintainers who need to publish a new release.
    ```bash
    bundle install              # Installs gem-release
    yarn global add release-it  # Installs release-it for npm publishing
-   gh --version                # Required only if you plan to run sync_github_release
+   gh --version                # Required for automatic GitHub release creation
    ```
 
 2. **Ensure you have publishing access:**
@@ -19,24 +19,37 @@ This guide is for Shakapacker maintainers who need to publish a new release.
 3. **Enable 2FA on both platforms:**
    - npm: 2FA is required for publishing
    - RubyGems: 2FA is required for publishing
-4. **If you plan to run `sync_github_release`, authenticate GitHub CLI:**
+
+4. **Authenticate GitHub CLI:**
    - Run `gh auth login` and ensure your account/token has write access to this repository
+   - Required for automatic GitHub release creation after publishing
 
 ## Release Process
 
-### 1. Prepare the Release
+### 1. Update the Changelog
 
-Before running the release task:
+**Always update CHANGELOG.md before running the release task.** The release task reads the version from CHANGELOG.md and automatically creates a GitHub release from the changelog section.
 
 1. Ensure all desired changes are merged to `main` branch
-2. Ensure your working directory is clean (`git status` shows no uncommitted changes)
+2. Run `/update-changelog release` (or `rc` or `beta` for prereleases) to:
+   - Find merged PRs missing from the changelog
+   - Add changelog entries under the appropriate category headings
+   - Auto-compute the next version based on changes (breaking → major, features → minor, fixes → patch)
+   - Stamp the version header (e.g., `## [v9.6.0] - March 7, 2026`)
+3. Review the changelog entries and verify the computed version
+4. Commit and push CHANGELOG.md
+
+If you forget this step, the release task will print a warning and the GitHub release will need to be created manually afterward using `sync_github_release`.
 
 ### 2. Run the Release Task
 
-The automated release task handles the entire release process:
+The simplest way to release is with no arguments — the task reads the version from CHANGELOG.md:
 
 ```bash
-# For a specific version (e.g., 9.1.0)
+# Recommended: reads version from CHANGELOG.md (requires step 1)
+bundle exec rake create_release
+
+# For a specific version (overrides CHANGELOG.md detection)
 bundle exec rake "create_release[9.1.0]"
 
 # For a beta release (note: use period, not dash)
@@ -45,14 +58,6 @@ bundle exec rake "create_release[9.2.0.beta.1]"  # Creates npm package 9.2.0-bet
 # For a release candidate
 bundle exec rake "create_release[9.6.0.rc.0]"
 
-# Auto-calculate next prerelease and confirm before publishing
-bundle exec rake "create_prerelease[9.6.0]"      # defaults to rc -> 9.6.0.rc.0 or 9.6.0.rc.1, etc.
-bundle exec rake "create_prerelease[9.6.0,rc]"   # -> 9.6.0.rc.0 or 9.6.0.rc.1, etc.
-bundle exec rake "create_prerelease[9.6.0,beta]" # -> 9.6.0.beta.0 or 9.6.0.beta.1, etc.
-
-# For a patch version bump (auto-increments)
-bundle exec rake create_release  # prompts to confirm computed patch version
-
 # Dry run to test without publishing
 bundle exec rake "create_release[9.1.0,true]"
 
@@ -61,9 +66,17 @@ RELEASE_VERSION_POLICY_OVERRIDE=true bundle exec rake "create_release[9.1.0]"
 bundle exec rake "create_release[9.1.0,false,true]"
 ```
 
+When called with no arguments, `create_release`:
+
+1. Reads the first versioned header from CHANGELOG.md (e.g., `## [v9.6.0]`)
+2. Compares it to the current gem version
+3. If the changelog version is newer, prompts for confirmation and uses it
+4. If no new version is found, falls back to a patch bump
+
 Dry runs use a temporary git worktree so version bumps and installs do not modify your current checkout.
 
-`create_release` and `create_prerelease` validate release-version policy before publishing:
+`create_release` validates release-version policy before publishing:
+
 - Target version must be greater than the latest tagged release.
 - If the versioned target changelog section exists (`## [vX.Y.Z...]`; not `UNRELEASED`), it maps to expected bump type:
   - Breaking changes => major bump
@@ -72,8 +85,9 @@ Dry runs use a temporary git worktree so version bumps and installs do not modif
   - Other headings => no inferred bump level (consistency check is skipped)
 
 Use override only when needed:
+
 - `RELEASE_VERSION_POLICY_OVERRIDE=true`
-- Or task arg override (`create_release[..., ..., true]`, `create_prerelease[..., ..., ..., true]`)
+- Or task arg override (`create_release[..., ..., true]`)
 
 ### 3. What the Release Task Does
 
@@ -81,6 +95,7 @@ The `create_release` task automatically:
 
 1. **Validates release prerequisites**:
    - Verifies npm authentication
+   - Warns if CHANGELOG.md section is missing for the target version
 2. **Pulls latest changes** from the repository
 3. **Bumps version numbers** in:
    - `lib/shakapacker/version.rb` (Ruby gem version)
@@ -95,31 +110,9 @@ The `create_release` task automatically:
    - Runs `bundle install` to update `Gemfile.lock`
    - Runs `npm install` to update `package-lock.json` (yarn.lock may also be updated for multi-package-manager compatibility testing)
 7. **Commits and pushes lockfile changes** automatically
+8. **Creates GitHub release** from CHANGELOG.md (if the matching section exists)
 
-### 4. Sync GitHub Release (Optional, After Publish)
-
-If you want GitHub Releases, do that as a separate step after publishing.
-Requires GitHub CLI (`gh`) with write access to this repository:
-
-Legacy note: `SKIP_GITHUB_RELEASE=true` is no longer used by release tasks. GitHub release creation is now an explicit, separate step via `sync_github_release`.
-
-1. Run `bundle exec rake update_changelog`
-2. Update `CHANGELOG.md` with the published version section
-   - For prerelease entries, use npm semver header format with dashes, for example `## [v9.6.0-rc.1]`
-3. Commit `CHANGELOG.md`
-4. Run:
-
-```bash
-# Stable
-bundle exec rake "sync_github_release[9.6.0]"
-
-# Prerelease
-bundle exec rake "sync_github_release[9.6.0.rc.1]"
-```
-
-`sync_github_release` reads release notes from the matching `CHANGELOG.md` section and creates/updates the GitHub release for the corresponding tag.
-
-### 5. Version Format
+### 4. Version Format
 
 **Important:** Use Ruby gem version format (no dashes):
 
@@ -131,6 +124,11 @@ The task automatically converts Ruby gem format to npm semver format:
 - Ruby: `9.2.0.beta.1` → npm: `9.2.0-beta.1`
 - Ruby: `9.0.0.rc.2` → npm: `9.0.0-rc.2`
 
+**CHANGELOG.md headers** use npm semver format (with dashes):
+
+- `## [v9.6.0-rc.1]` — correct (matches git tag format)
+- `## [v9.6.0.rc.1]` — wrong (RubyGems format, will not be found by release tasks)
+
 **Examples:**
 
 ```bash
@@ -143,27 +141,25 @@ bundle exec rake "create_release[9.2.0.beta.1]"  # Gem: 9.2.0.beta.1, npm: 9.2.0
 # Release candidate
 bundle exec rake "create_release[10.0.0.rc.1]"  # Gem: 10.0.0.rc.1, npm: 10.0.0-rc.1
 
-# Auto-next prerelease (recommended)
-bundle exec rake "create_prerelease[10.0.0,rc]"  # picks rc.0 then rc.1, etc., with confirmation
+# Prerelease: use /update-changelog rc first, then create_release reads it
+bundle exec rake create_release  # reads v10.0.0-rc.0 from CHANGELOG.md
 ```
 
-The `create_prerelease` task defaults to `rc` if prerelease type is omitted. Use `beta` explicitly when needed.
-
-### 6. During the Release
+### 5. During the Release
 
 1. When prompted for **npm OTP**, enter your 2FA code from your authenticator app
 2. Accept defaults for release-it options
 3. When prompted for **RubyGems OTP**, enter your 2FA code
-4. If using patch auto-bump (`create_release` with no version), confirm the computed patch version when prompted
-5. If using `create_prerelease`, confirm the computed next prerelease version when prompted
-6. The script will automatically commit and push lockfile updates
+4. If using `create_release` with no version, confirm the version detected from CHANGELOG.md (or the computed patch version)
+5. The script will automatically commit and push lockfile updates
+6. The script will automatically create a GitHub release (if CHANGELOG.md section exists)
 
-### 7. After Release
+### 6. After Release
 
 1. Verify the release on:
    - [npm](https://www.npmjs.com/package/shakapacker)
    - [RubyGems](https://rubygems.org/gems/shakapacker)
-   - [GitHub releases](https://github.com/shakacode/shakapacker/releases) if you ran `sync_github_release`
+   - [GitHub releases](https://github.com/shakacode/shakapacker/releases)
 
 2. Check that the lockfile commit was pushed:
 
@@ -177,6 +173,25 @@ The `create_prerelease` task defaults to `rc` if prerelease type is omitted. Use
    - Tweet about major releases
    - Update documentation if needed
 
+### Syncing GitHub Releases Manually
+
+If the automatic GitHub release creation was skipped (e.g., CHANGELOG.md section was missing during release), you can create it manually after updating the changelog:
+
+1. Update `CHANGELOG.md` with the published version section
+   - For prerelease entries, use npm semver header format with dashes, for example `## [v9.6.0-rc.1]`
+2. Commit and push `CHANGELOG.md`
+3. Run:
+
+```bash
+# Stable
+bundle exec rake "sync_github_release[9.6.0]"
+
+# Prerelease
+bundle exec rake "sync_github_release[9.6.0.rc.1]"
+```
+
+`sync_github_release` reads release notes from the matching `CHANGELOG.md` section and creates/updates the GitHub release for the corresponding tag.
+
 ## Troubleshooting
 
 ### Uncommitted Changes After Release
@@ -202,7 +217,7 @@ If publishing fails partway through:
 
 ### GitHub Release Sync Fails
 
-If package publishing succeeds but `sync_github_release` fails:
+If package publishing succeeds but GitHub release creation fails:
 
 1. Fix GitHub auth (`gh auth login`) or permissions
 2. Ensure `CHANGELOG.md` has matching header `## [vX.Y.Z...]` (npm format for prereleases)
@@ -212,14 +227,6 @@ If package publishing succeeds but `sync_github_release` fails:
    bundle exec rake "sync_github_release[<gem_version>]"
    ```
 
-### Legacy `SKIP_GITHUB_RELEASE` Usage
-
-If your CI or local runbook still sets `SKIP_GITHUB_RELEASE=true`:
-
-1. `create_release` and `create_prerelease` now always skip GitHub release creation by design
-2. Remove `SKIP_GITHUB_RELEASE` from scripts to avoid confusion
-3. Run `sync_github_release` explicitly when you want to create or update a GitHub release
-
 ### Wrong Version Format
 
 If you accidentally use npm format (with dashes):

data/lib/shakapacker/utils/version_syntax_converter.rb

@@ -17,7 +17,7 @@ module Shakapacker
                   .tr("-", ".")
                   .strip
                   .match(/(\d.*)/)
-        match.present? ? match[0] : nil
+        match ? match[0] : nil
       end
     end
   end

data/lib/shakapacker/version.rb

@@ -1,4 +1,4 @@
 module Shakapacker
   # Change the version in package.json too, please!
-  VERSION = "9.6.0.rc.1".freeze
+  VERSION = "9.6.0.rc.2".freeze
 end

data/package.json

@@ -1,6 +1,6 @@
 {
   "name": "shakapacker",
-  "version": "9.6.0-rc.1",
+  "version": "9.6.0-rc.2",
   "description": "Use webpack to manage app-like JavaScript modules in Rails",
   "homepage": "https://github.com/shakacode/shakapacker",
   "bugs": {

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: shakapacker
 version: !ruby/object:Gem::Version
-  version: 9.6.0.rc.1
+  version: 9.6.0.rc.2
 platform: ruby
 authors:
 - David Heinemeier Hansson
@@ -426,7 +426,7 @@ homepage: https://github.com/shakacode/shakapacker
 licenses:
 - MIT
 metadata:
-  source_code_uri: https://github.com/shakacode/shakapacker/tree/v9.6.0-rc.1
+  source_code_uri: https://github.com/shakacode/shakapacker/tree/v9.6.0-rc.2
 rdoc_options: []
 require_paths:
 - lib