Repository navigation
meta: Use built-in postReleaseBump for the development version - #951
Merged
Merged
Conversation
Replace the postReleaseCommand that ran npm version preminor --preid=dev and committed/pushed by hand with postReleaseBump, and raise minVersion so an older Craft fails loudly instead of silently skipping the bump. Depends on #950 shipping in 3.7.0. Co-Authored-By: BYK <126780+BYK@users.noreply.github.com>
Co-Authored-By: BYK <126780+BYK@users.noreply.github.com>
BYK
added a commit
that referenced
this pull request
Nov 2, 2026
) Closes #949. Many repos use `postReleaseCommand` for one job: write the next development version, commit, pull with rebase, and push. In almost every case the script just re-runs the repo's own pre-release bump with a dev version. This PR builds that into Craft as an opt-in setting: ```yaml postReleaseBump: true # defaults: minor + -dev.0 postReleaseBump: patch # shorthand for { bump: patch } postReleaseBump: bump: minor # patch | minor | major | calver version: '{{version}}-dev.0' # template; {{version}} = next version ``` ## Behavior - **Computing the dev version:** - `bump` picks the next version: a semver `patch`/`minor`/`major` increment, or `calver`, the first version of the next CalVer period under `versioning.calver.format` (e.g. `26.10.1` → `26.11.0`, `26.12.3` → `27.1.0`). - The default is `calver` when `versioning.policy` is `calver`, otherwise `minor`. - `version` is a template, rendered with `renderTemplateSafe` (`{{version}}` = next version). The default `{{version}}-dev.0` matches `npm version preminor --preid=dev`. A value with no placeholder, such as `nightly`, is used as is. - **Writing it:** Craft reuses `runPreReleaseCommand`, the step `craft prepare` uses: the `preReleaseCommand` when set (with `CRAFT_NEW_VERSION` set to the dev version), otherwise the automatic target bumps in the selected workspace. It then commits `meta: Bump new development version` + `#skip-changelog` with `--all`, runs `git pull --rebase` (aborting the rebase if that fails), and pushes to the merge target. - **Refactors:** - `runPreReleaseCommand` moves from `commands/prepare.ts` to `utils/preReleaseCommand.ts`, so `publish` doesn't import `prepare`, which already imports `publish`. - The pull logic is now a shared `pullWithRebase` helper. - **When the bump is skipped:** - The release branch wasn't merged: `noMerge`, a partial-target publish, or a merge or push failure. A `BranchCleanupError` still counts as merged. - The released version is a pre-release. - Nothing wrote a version. - Dry runs only log the version they would write. - **A failed bump warns and reports to Sentry, but doesn't fail the release**, the same way a failed merge is handled. - **Schema:** `true` and the bump-type shorthand normalize to the object form, so `publish` only handles one shape. The dev marker should stay a pre-release (`-dev.0`): `+dev` build metadata is ignored when ordering versions, dropped by npm, and rejected by PyPI. - **Workspaces** inherit the setting. A workspace can opt out with `postReleaseBump: false`. - **Order:** the bump runs before `postReleaseCommand`. ## Who can switch A survey of getsentry repos found these post-release scripts. Each one re-runs the repo's bump script with a dev version and then commits and pushes: | repo | config | | --- | --- | | craft | `postReleaseBump: true` → #951 | | sentry, snuba (calver) | `postReleaseBump: { version: '{{version}}.dev0' }` → `26.11.0.dev0` after `26.10.1`, same as today | | self-hosted | `postReleaseBump: { version: nightly }` | | sentry-godot | `postReleaseBump: true` (`2.5.0-dev.0`, vs. `-dev` from its current script). That script doesn't seem to run: `main` is still `2.4.0` after the 2.4.0 release, and it calls `'pwsh.\scripts\bump-version.ps1'`. | | toolkit | `postReleaseBump: true` re-runs `bump-version.ts` in pre mode. Its frontmatter sync only happens in `--post` mode today, so it either needs a small script change or #948 | Migration PRs follow once this ships in 3.7.0. ## Checks - `tsc --noEmit`, `pnpm lint`, and `prettier --check` all pass. - Tests: `vitest run src/commands/__tests__ src/__tests__/config.test.ts src/utils/__tests__/calver.test.ts`: 235 passed. That covers: - publish: semver, CalVer, template, and literal versions; passing the `preReleaseCommand` through; commit/pull/push; and every skip and failure path. - `getNextCalVerPeriod`: month and day formats, year rollover, and versions that don't match. - schema: `true`, `false`, the object form, the bump-type shorthand and how each normalizes, and invalid values such as `preminor`. - In my sandbox, the full suite had 4 failing files on both this branch and `master`. The causes are sandbox-specific: a forced Git identity breaks commits in tests, npm env vars leak in, and the default `pnpm` is v12. CI is the source of truth. <!-- junior-request-attribution:start --> via @BYK. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:local%3Aweb%3Af8508ca3568070a0389d1c35 --> -- [View Session in Sentry](https://sentry.sentry.io/explore/conversations/local%3Aweb%3Af8508ca3568070a0389d1c35/?project=4510944073809921) <!-- junior-session-footer:end --> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: BYK <126780+BYK@users.noreply.github.com>
BYK
marked this pull request as ready for review
November 2, 2026 11:53
BYK
approved these changes
Nov 2, 2026
8 tasks done
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moves Craft's own release config to the built-in post-release bump from #950. That's the follow-up for #949.
Changes
postReleaseCommand→postReleaseBump: true. The old command rannpm version preminor --preid=dev, then committed with#skip-changelog, pulled with rebase, and pushed. Now Craft computes the default{{version}}-dev.0(3.7.0→3.8.0-dev.0, the same as before) and writes it through the existingpreReleaseCommand, which runsnpm version $CRAFT_NEW_VERSION. The commit message stays the same.minVersion: '2.14.0'→'3.7.0'. An older Craft drops the unknownpostReleaseBumpkey without an error, so this makes it fail loudly instead of skipping the bump. The only behavior gates between those versions are:preReleaseCommand.One small behavior change: after a pre-release, Craft now skips the bump. The old script bumped anyway.
Merge order
This stays a draft until #950 is merged and shipped in 3.7.0.
craft preparehere runs the build artifact frommaster, butpublishmay run a released Craft. Merging early could fail a release on theminVersioncheck.Checks
dist/craftfor the final schema. The feat(publish): Add built-in development version bump after release #950 config tests coverpostReleaseBump: true.prettier --check .craft.ymlpasses.via @BYK.
--
View Session in Sentry