## Description Releases of non-`fast-check` packages (`ava`, `jest`, `vitest`, `worker`, `poisoning`, `packaged`) were being flagged as the repository's "latest" release alongside `fast-check` itself. From an end-user point of view, browsing https://github.com/dubzzz/fast-check/releases/latest could land on a `@fast-check/jest` (or other sub-package) release instead of the actual latest `fast-check` version. After this change, only `fast-check` releases take the repo-level "latest" flag; sub-package releases are still created normally, just without claiming `/releases/latest`. Root cause: `softprops/action-gh-release@v3` parses its `make_latest` input with a strict equality check — only the exact strings `'true'`, `'false'`, or `'legacy'` are accepted; anything else is dropped to `undefined`, in which case the action does not forward the field and the GitHub API falls back to its default of marking the release as latest. The previous expression returned a string, but after GitHub Actions substituted it into the workflow YAML the resulting token was unquoted (`make_latest: false`), which YAML re-parses as a boolean. Wrapping the whole expression in double quotes keeps the value a string end-to-end so the action receives literal `'true'` for `fast-check` and `'false'` for every other package. Impact: patch — CI/release workflow only, no runtime code touched. The change is scoped to a single line in `.github/workflows/create-release.yml`, so the PR stays on one concern. No new tests are added: this is a workflow fix that cannot be exercised in the unit-test suite; the behavior will be observable on the next non-`fast-check` release dispatch (where the draft must come up with the "Set as the latest release" checkbox unchecked). ## Checklist — _Don't delete this checklist and make sure you do the following before opening the PR_ - [ ] I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool - [ ] I flagged the impact of my change (minor / patch / major) either by running `pnpm run bump` or by following the instructions from the changeset bot - [ ] I kept this PR focused on a single concern and did not bundle unrelated changes - [ ] I followed the [gitmoji](https://gitmoji.dev/) specification for the name of the PR, including the package scope (e.g. `🐛(vitest) Something...`) when the change targets a package other than `fast-check` - [ ] I added relevant tests and they would have failed without my PR (when applicable) Co-authored-by: Claude <noreply@anthropic.com>