diff --git a/README.md b/README.md index 9804d58..ba5400a 100644 --- a/README.md +++ b/README.md @@ -143,14 +143,13 @@ Tools like semantic-release infer version bumps from commit messages (`feat:` ## Why not just use changesets? -Bumpy is built as a successor to [πŸ¦‹changesets](https://github.com/changesets/changesets). Changesets is mature and widely adopted, but has stagnated - hundreds of open issues around core design problems that are unlikely to be fixed without a rewrite. See [differences from changesets](https://github.com/dmno-dev/bumpy/blob/main/docs/differences-from-changesets.md) for a detailed comparison with links to specific issues. The biggest pain points bumpy addresses: +Bumpy is built as a successor to [πŸ¦‹changesets](https://github.com/changesets/changesets). Changesets is mature and widely adopted, and its v3 release (August 2026) fixed many long-standing complaints - forced peer-dep major bumps, unresolved `workspace:` ranges, no non-interactive mode, publish ordering. The remaining differences are structural. See [differences from changesets](https://github.com/dmno-dev/bumpy/blob/main/docs/differences-from-changesets.md) for a detailed comparison with links to specific issues. The biggest ones: -- **Sane dependency propagation** - changesets hardcodes aggressive behavior where a minor bump triggers a major bump on all peer dependents. Bumpy uses a [three-phase algorithm](https://github.com/dmno-dev/bumpy/blob/main/docs/version-propagation.md) with sensible defaults and full configurability. -- **Workspace protocol resolution** - changesets uses `npm publish` even in pnpm/yarn workspaces, so `workspace:^` and `catalog:` protocols are NOT resolved, resulting in broken published packages. -- **Custom publish commands** - changesets is hardcoded to `npm publish`. Bumpy supports per-package custom publish for VSCode extensions, Docker images, JSR, etc. -- **Flexible package management** - changesets treats all private packages the same. Bumpy lets you include/exclude any package individually. +- **Configurable dependency propagation** - changesets hardcodes peer dep behavior (v2 forced major bumps on all peer dependents; v3 forces patch, assuming every peer change is non-breaking). Bumpy uses a [three-phase algorithm](https://github.com/dmno-dev/bumpy/blob/main/docs/version-propagation.md) that matches the triggering bump level by default, with full configurability. +- **Custom publish commands** - changesets only publishes npm packages. Bumpy supports per-package custom publish for VSCode extensions, Docker images, JSR, etc. +- **Catalog & protocol resolution** - changesets v3 resolves `workspace:^` by delegating to pnpm/yarn at publish time, but `catalog:` is still unsupported. Bumpy resolves all workspace protocols and catalogs (pnpm, Bun, Yarn) itself - so resolution also works for custom publish targets. - **CI without a separate action or bot** - changesets requires installing a [GitHub App](https://github.com/apps/changeset-bot) _and_ using a [separate GitHub Action](https://github.com/changesets/action). Bumpy replaces both with two CLI commands (`bumpy ci check` + `bumpy ci release`) that run directly in your workflows - no extra repos to trust, no app installation requiring org admin approval. -- **Prerelease channels that don't corrupt state** - changesets' prerelease mode is described in [their own docs](https://github.com/changesets/changesets/blob/main/docs/prereleases.md) as "very complicated" with states "very hard to fix." Bumpy uses [branch-based channels](https://github.com/dmno-dev/bumpy/blob/main/docs/prereleases.md) where prerelease versions are never committed - no global mode file to poison unrelated releases. +- **Prerelease channels that don't corrupt state** - changesets' prerelease mode is described in [their own docs](https://github.com/changesets/changesets/blob/main/docs/prereleases.md) as "very complicated" with states "very hard to fix" (improved bookkeeping in v3, but still a committed global mode). Bumpy uses [branch-based channels](https://github.com/dmno-dev/bumpy/blob/main/docs/prereleases.md) where prerelease versions are never committed - no global mode file to poison unrelated releases. - **Automatic migration** - `bumpy init` detects `.changeset/`, renames it to `.bumpy/`, migrates config, keeps pending files, and offers to uninstall `@changesets/cli`. ## Development diff --git a/docs/comparisons.md b/docs/comparisons.md index 2183204..b00c8e4 100644 --- a/docs/comparisons.md +++ b/docs/comparisons.md @@ -8,21 +8,21 @@ There are several great tools in the release management space, each with differe ## Changesets -[Changesets](https://github.com/changesets/changesets) is the most direct comparison β€” bumpy uses the same bump-file-per-PR model and is designed as a successor to it. Changesets is mature, widely adopted, and battle-tested across many large monorepos. +[Changesets](https://github.com/changesets/changesets) is the most direct comparison β€” bumpy uses the same bump-file-per-PR model and is designed as a successor to it. Changesets is mature, widely adopted, and battle-tested across many large monorepos. The v3 release (August 2026) fixed many long-standing v2 complaints β€” forced peer-dep major bumps, unresolved `workspace:` ranges, no non-interactive `add`, publish ordering β€” which narrows the gap, though the remaining differences below are structural. **Where changesets shines:** - Proven at scale with years of production use across the ecosystem - Large community with extensive documentation and third-party integrations -- Stable, well-understood behavior +- v3 modernized the core: sane peer-dep bumps, publishes routed through pnpm/yarn, dependency-ordered publishing, better failure recovery **Where bumpy differs:** -- **Dependency propagation** β€” changesets hardcodes aggressive peer dep behavior (a minor bump can trigger major bumps on dependents). Bumpy uses a [configurable three-phase algorithm](./version-propagation.md) with sensible defaults. -- **Workspace protocols** β€” changesets uses `npm publish` even in pnpm/yarn workspaces, so `workspace:^` and `catalog:` protocols may not be resolved correctly. Bumpy resolves these before publishing. -- **Custom publish commands** β€” changesets is locked to `npm publish`. Bumpy supports per-package custom commands for VSCode extensions, Docker images, JSR, etc. +- **Dependency propagation** β€” changesets hardcodes peer dep behavior (v2 forced major bumps on dependents; v3 forces patch β€” assuming every peer change is non-breaking). Bumpy uses a [configurable three-phase algorithm](./version-propagation.md) that matches the triggering bump level by default. +- **Catalogs & protocol resolution** β€” changesets v3 resolves `workspace:^` by delegating to pnpm/yarn at publish time, but `catalog:` support is still open. Bumpy resolves all workspace protocols and catalogs (pnpm, Bun, Yarn) itself, so resolution also works with custom publish targets. +- **Custom publish commands** β€” changesets only publishes npm packages. Bumpy supports per-package custom commands for VSCode extensions, Docker images, JSR, etc. - **CI setup** β€” changesets requires a [GitHub App](https://github.com/apps/changeset-bot) and a [separate GitHub Action](https://github.com/changesets/action). Bumpy uses two CLI commands (`bumpy ci check` + `bumpy ci release`) that run directly in your workflows. -- **Non-interactive CLI** β€” `bumpy add` works fully non-interactively, which is important for CI/CD and AI-assisted workflows. +- **Prereleases** β€” changesets uses a committed global "pre mode" (improved bookkeeping in v3, but still a shared state file with known footguns). Bumpy uses [branch-based channels](./prereleases.md) with no committed prerelease state. For a detailed breakdown with links to specific changesets issues, see [Differences from Changesets](./differences-from-changesets.md). diff --git a/docs/differences-from-changesets.md b/docs/differences-from-changesets.md index afceae0..af951a3 100644 --- a/docs/differences-from-changesets.md +++ b/docs/differences-from-changesets.md @@ -1,100 +1,102 @@ # Differences from Changesets -Bumpy is built as a modern successor to [changesets](https://github.com/changesets/changesets). This document tracks the pain points, missing features, and design problems in changesets that bumpy addresses (or plans to address), with links back to the relevant GitHub issues. +Bumpy is built as a modern successor to [changesets](https://github.com/changesets/changesets). This document tracks the real differences between the two tools, with links back to the relevant GitHub issues. + +> **Changesets v3 note:** [`@changesets/cli@3.0.0`](https://github.com/changesets/changesets/releases/tag/%40changesets%2Fcli%403.0.0) and [`changesets/action@v2`](https://github.com/changesets/action/releases/tag/v2.0.0) shipped on 2026-08-11 β€” a major release that fixed many long-standing v2 complaints, including **15+ of the issues this doc previously tracked** (forced peer-dep major bumps, `workspace:` protocol resolution, non-interactive `add`, topological publish order, publish failure handling, and more). Credit where due β€” it's a substantial cleanup. This doc now compares against **v3**; the things v3 fixed are summarized in [Fixed in changesets v3](#fixed-in-changesets-v3) at the bottom. --- -## Implemented +## Remaining differences (vs changesets v3) -### Sane dependency bump propagation +### Configurable dependency bump propagation -Changesets hardcodes aggressive behavior: a **minor** bump on a package triggers a **major** bump on all packages that peer-depend on it. This is the single biggest community complaint. +Changesets v2 hardcoded the most aggressive behavior possible: a **minor** bump on a package triggered a **major** bump on all packages that peer-depend on it β€” the single biggest community complaint (fixed in v3). Changesets v3 hardcodes the opposite extreme: peer dependency updates now always bump dependents by **patch**, i.e. every peer dep change is assumed non-breaking, and if it isn't you must remember to add a manual major changeset. Neither version lets you configure the behavior. Bumpy splits propagation into three phases inside an iterative loop: -- **Phase A (always runs):** fixes broken version ranges β€” peer dep bumps match the triggering bump level, regular deps get patch, dev deps are skipped. Cannot be disabled. +- **Phase A (always runs):** fixes broken version ranges β€” peer dep bumps **match the triggering bump level** (a minor bump on `core` β†’ minor bump on `plugin`; not blanket major like changesets v2, not blanket patch like v3), regular deps get patch, dev deps are skipped. Cannot be disabled. - **Phase B:** enforces fixed/linked group constraints. - **Phase C (opt-in):** proactive propagation via configurable `dependencyBumpRules` and `cascadeTo` rules. Off by default (`updateInternalDependencies: "out-of-range"`). -Key differences from changesets: +Other propagation differences that remain: -- Out-of-range peer dep bumps match the triggering bump level (not always major) β€” a minor bump on `core` β†’ minor bump on `plugin`, not major -- Dev deps never propagate by default (opt specific ones in per-package via `releaseTriggeringDevDeps`, e.g. bundled deps) +- Dev deps never propagate by default, but specific ones can be opted in per-package via `releaseTriggeringDevDeps` (e.g. bundled deps) β€” still not configurable in changesets - `cascadeTo` config for source-side "when I change, cascade to these packages" - Per-bump-file `none` to acknowledge changes without triggering a direct bump - Warns about `^0.x` caret range gotchas and `workspace:*` on peer deps See [docs/version-propagation.md](./version-propagation.md) for the full algorithm. -- [changesets#1011](https://github.com/changesets/changesets/issues/1011) β€” peerDependencies cause unnecessary major bumps (70+ thumbs-up) -- [changesets#822](https://github.com/changesets/changesets/issues/822) β€” unexpected major version bumps from peer deps -- [changesets#1126](https://github.com/changesets/changesets/issues/1126) β€” peer dep bumping is too aggressive -- [changesets#1228](https://github.com/changesets/changesets/issues/1228) β€” allow configuring peer dep bump behavior / 0.x versions -- [changesets#827](https://github.com/changesets/changesets/issues/827) β€” peer dep bump propagation should be configurable -- [changesets#960](https://github.com/changesets/changesets/issues/960) β€” unexpected version bumps in monorepos +Still-open changesets issues in this area: + - [changesets#944](https://github.com/changesets/changesets/issues/944) β€” devDependencies should be configurable (17 thumbs-up) - [changesets#568](https://github.com/changesets/changesets/issues/568) β€” allow dependents to not be automatically bumped - [changesets#1128](https://github.com/changesets/changesets/issues/1128) β€” `updateInternalDependencies` only on certain packages - [changesets#808](https://github.com/changesets/changesets/issues/808) β€” ignore some packages on `updateInternalDependencies` - [changesets#1819](https://github.com/changesets/changesets/issues/1819) β€” support major version propagation to dependents (`bumpAs: "match"`) -- [changesets#1735](https://github.com/changesets/changesets/issues/1735) β€” unidirectional dependency relationships (solved by `cascadeTo`) ### Custom publish commands -Changesets is hardcoded to `npm publish`. Bumpy supports per-package custom publish commands for VS Code extensions, Docker images, JSR, private registries, or anything else. +Changesets only publishes to npm-compatible registries β€” v3 now routes publishes through the workspace's own package manager CLI (npm, pnpm, or Yarn Berry), but there's still no way to publish anything that isn't an npm package. Bumpy supports per-package custom publish commands for VS Code extensions, Docker images, JSR, private registries, or anything else. - [changesets#399](https://github.com/changesets/changesets/issues/399) β€” arbitrary publish steps (14 comments) - [changesets#1318](https://github.com/changesets/changesets/issues/1318) β€” JSR support (39 thumbs-up) -- [changesets#1717](https://github.com/changesets/changesets/issues/1717) β€” JSR custom publish (12 thumbs-up) - [changesets#1230](https://github.com/changesets/changesets/discussions/1230) β€” publishing Docker images - [changesets#1297](https://github.com/changesets/changesets/discussions/1297) β€” publishing VS Code extensions -### Workspace protocol resolution +### Catalog resolution (and workspace protocols beyond the package manager) -Changesets uses `npm publish` even in Yarn/pnpm workspaces, so `workspace:^` and `catalog:` protocols are NOT resolved, resulting in broken published packages. Bumpy resolves all workspace protocols correctly before publish. +Changesets v3 fixed the biggest hole here: publishes now go through the package manager's own CLI, so `workspace:^` ranges get resolved by pnpm/Yarn at publish time ([#432](https://github.com/changesets/changesets/issues/432), [#1454](https://github.com/changesets/changesets/issues/1454) et al β€” closed). What remains: -- [changesets#432](https://github.com/changesets/changesets/issues/432) β€” workspace: ranges not resolved (33 comments) -- [changesets#1290](https://github.com/changesets/changesets/issues/1290) β€” workspace:^ not handled correctly -- [changesets#1421](https://github.com/changesets/changesets/issues/1421) β€” workspace:^ bumped on patch despite `updateInternalDependencies: "minor"` -- [changesets#1229](https://github.com/changesets/changesets/issues/1229) β€” workspace: protocol causes publish failures -- [changesets#1468](https://github.com/changesets/changesets/issues/1468) β€” workspace:^ published as-is (16 thumbs-up) -- [changesets#1454](https://github.com/changesets/changesets/issues/1454) β€” publishing with Yarn is broken (38 thumbs-up) -- [changesets#1707](https://github.com/changesets/changesets/issues/1707) β€” pnpm workspace catalog support (20 thumbs-up) +- **`catalog:` support is still open** β€” [changesets#1707](https://github.com/changesets/changesets/issues/1707) (20 thumbs-up). Bumpy resolves pnpm catalogs, Bun catalogs, and Yarn catalogs (from `.yarnrc.yml`). +- Changesets' resolution only happens inside the package manager's publish. Bumpy resolves all workspace protocols itself before publish, so resolution also works for custom publish commands (packing a VS Code extension, publishing to JSR, etc.). + +### Local bump file verification -### Non-interactive CLI +`bumpy check` verifies that changed packages on the current branch have corresponding bump files. Compares your branch to the base branch, maps changed files to packages. By default it only fails if no bump files exist at all (matching changesets behavior). Use `--strict` to require every changed package to be covered, `--no-fail` for advisory-only mode, or `--hook pre-commit`/`--hook pre-push` to control which bump files count based on their git status. No GitHub API needed. -`bumpy add` works fully non-interactively for CI/CD pipelines and AI-assisted development. +Changesets still has no local equivalent β€” users rely on the CI bot comment to catch missing bump files after pushing. -- [changesets#979](https://github.com/changesets/changesets/issues/979) β€” non-interactive mode (15 thumbs-up) -- [changesets#1118](https://github.com/changesets/changesets/discussions/1118) β€” CLI automation support +### CI without a separate action or bot -### Provenance, staged publishing, and custom publish args +Changesets still requires **two** separate pieces of CI infrastructure beyond the CLI: -Bumpy has first-class `provenance` and `npmStaged` config options, plus support for passing extra args to the publish command. +1. **[changeset-bot](https://github.com/apps/changeset-bot)** β€” a GitHub App you must install on your repo that watches PRs and posts "missing changeset" comments +2. **[changesets/action](https://github.com/changesets/action)** β€” a GitHub Action (separate repo) that handles creating the version PR and publishing. The v2 action (released alongside CLI v3) modernized a lot β€” pushes via the GitHub API, trusted-publishing-first auth, granular sub-actions β€” but it's still a separate repository with its own release cadence, breaking changes (v2 renamed most inputs), and a hard requirement on CLI v3. -- [changesets#1152](https://github.com/changesets/changesets/issues/1152) β€” provenance support (36 thumbs-up, 26 comments) +This means you're trusting and auditing two additional dependencies with write access to your repo. The bot requires GitHub App installation (org admin approval in many orgs). -### Topological publish order +Bumpy replaces all of this with two CLI commands you run directly in standard workflows β€” `bumpy ci check` (PR comments) and `bumpy ci release` (version PR + publishing). No GitHub App to install, no separate action to trust. Your CI runs the same `@varlock/bumpy` package you already depend on. Works on any CI provider that can run shell commands β€” not just GitHub Actions. -Packages are published in dependency order so a partial failure doesn't leave the registry in a broken state. +- [changesets#134](https://github.com/changesets/changesets/issues/134) β€” requests for GitHub check integration (only available via bot) +- [changesets#1812](https://github.com/changesets/changesets/issues/1812) β€” can't filter which PRs the bot watches +- [changesets#946](https://github.com/changesets/changesets/issues/946) β€” bot doesn't check for new changes +- [changesets#43](https://github.com/changesets/changesets/issues/43) β€” can't customize bot messages -- [changesets#238](https://github.com/changesets/changesets/issues/238) β€” publish order should respect dependency graph (11 comments) +### Prerelease channels that actually work -### Default access: public +Changesets' prerelease mode is described in their own docs as "very complicated" with "mistakes that can lead to repository and publish states that are very hard to fix." v3 improved the bookkeeping (versioned changesets now move to a `.changeset/pre/` folder instead of being id-tracked in `pre.json`), but the fundamental design is unchanged: pre mode is still a committed global state file, so it still poisons unrelated merges, exiting pre still bumps ALL packages, counters still require committed version state, and dist-tags still can't be controlled per-release. -Bumpy defaults to `"access": "public"` since most open-source packages are public. Changesets defaults to `"restricted"`. +Bumpy replaces the mode with **branch-based channels** ([docs/prereleases.md](./prereleases.md)): a long-lived branch (e.g. `next`) maps to a prerelease line. Bump file location (`.bumpy//`) is the only state; prerelease versions are never committed β€” targets derive from bump files, counters from the registry. Promotion to stable is just a merge. -- [changesets#503](https://github.com/changesets/changesets/issues/503) β€” default access should be public (23 thumbs-up) +- [changesets#729](https://github.com/changesets/changesets/issues/729) β€” exiting pre mode bumps all versions (14 comments) +- [changesets#786](https://github.com/changesets/changesets/issues/786) β€” can't control dist-tag in pre mode (13 comments) +- [changesets#239](https://github.com/changesets/changesets/issues/239) β€” prerelease mode design issues +- [changesets#381](https://github.com/changesets/changesets/issues/381) β€” prerelease counters require committed state + +### First-class staged publishing and provenance config + +Changesets v3 gained useful building blocks here β€” `changeset pack`, `changeset publish-plan`, and `publish --from-pack-dir` enable pack-then-publish flows, and the provenance request ([#1152](https://github.com/changesets/changesets/issues/1152)) was closed because npm's trusted publishing (OIDC) now provides provenance automatically. Bumpy still goes further with explicit `provenance` and `npmStaged` config options, extra publish args, and a staged-release finalize flow (`bumpy publish finalize`) that keeps GitHub releases as drafts until staged packages actually go live. ### Publish dry run -`bumpy publish --dry-run` previews what would be published without actually doing it. +`bumpy publish --dry-run` previews the entire publish (including custom commands) without doing it. Changesets v3's new `publish-plan` command covers part of this β€” it inspects which packages would be published or tagged β€” but a true `publish --dry-run` is still open. - [changesets#614](https://github.com/changesets/changesets/issues/614) β€” dry run for publish (47 thumbs-up) ### Filtered/individual package publishing -`bumpy publish --filter "@myorg/core"` publishes only matching packages. Supports globs. Important for partial failure recovery and large monorepos. +`bumpy publish --filter "@myorg/core"` publishes only matching packages. Supports globs. Important for partial failure recovery and large monorepos. (v3 improved automatic partial-failure recovery, but there's still no manual filter.) - [changesets#1160](https://github.com/changesets/changesets/issues/1160) β€” filtered publish (34 thumbs-up) @@ -110,12 +112,16 @@ Bumpy includes the release date in every changelog heading by default. - [changesets#109](https://github.com/changesets/changesets/issues/109) β€” dates in changelog (17 thumbs-up) +### Default access: public + +Bumpy defaults to `"access": "public"` since most open-source packages are public. Changesets still defaults to `"restricted"`, though v3's interactive `init` now at least asks. + +- [changesets#503](https://github.com/changesets/changesets/issues/503) β€” default access should be public (23 thumbs-up) + ### Migration tool `bumpy init` detects `.changeset/` and automatically migrates β€” renaming the directory to `.bumpy/`, converting config, and keeping pending bump files. -- (Previously listed under Planned) - ### Auto-generate from commits `bumpy generate` scans commits on the current branch and auto-creates bump files. It works with any commit style β€” conventional commits get enhanced bump-level detection (`feat` β†’ minor, `fix` β†’ patch, `feat!` β†’ major), while all other commits are mapped to packages via changed file paths (defaulting to `patch`). Not a replacement for explicit bump files β€” a bridge for teams migrating from semantic-release, or a convenience when you want both. @@ -124,47 +130,12 @@ Bumpy includes the release date in every changelog heading by default. ### Pluggable changelog formatters -Custom changelog formatters with full context (release info, bump files, dates). Built-in `"default"` and `"github"` (with PR links + author attribution) formatters. Users can write custom formatters in TypeScript or JavaScript. Changesets' API is limited to two awkward string-returning functions β€” bumpy gives you the full context and you return the complete entry. +Custom changelog formatters with full context (release info, bump files, dates). Built-in `"default"` and `"github"` (with PR links + author attribution) formatters. Users can write custom formatters in TypeScript or JavaScript. Changesets' API is still limited to two awkward string-returning functions β€” bumpy gives you the full context and you return the complete entry. - [changesets#658](https://github.com/changesets/changesets/issues/658) β€” changelog titles not customizable (12 thumbs-up) - [changesets#556](https://github.com/changesets/changesets/issues/556) β€” changelog formatting (11 thumbs-up) - [changesets#995](https://github.com/changesets/changesets/issues/995) β€” getChangelogEntry API (12 thumbs-up) -### CI without a separate action or bot - -Changesets requires **two** separate pieces of CI infrastructure beyond the CLI: - -1. **[changeset-bot](https://github.com/apps/changeset-bot)** β€” a GitHub App you must install on your repo that watches PRs and posts "missing changeset" comments -2. **[changesets/action](https://github.com/changesets/action)** β€” a GitHub Action (separate repo) that handles creating the version PR and publishing - -This means you're trusting and auditing two additional dependencies with write access to your repo. The bot requires GitHub App installation (org admin approval in many orgs), and the action is a separate repository with its own release cadence and issues. - -Bumpy replaces all of this with two CLI commands you run directly in standard workflows β€” `bumpy ci check` (PR comments) and `bumpy ci release` (version PR + publishing). No GitHub App to install, no separate action to trust. Your CI runs the same `@varlock/bumpy` package you already depend on. Works on any CI provider that can run shell commands β€” not just GitHub Actions. - -- [changesets#134](https://github.com/changesets/changesets/issues/134) β€” requests for GitHub check integration (only available via bot) -- [changesets#1812](https://github.com/changesets/changesets/issues/1812) β€” can't filter which PRs the bot watches -- [changesets#946](https://github.com/changesets/changesets/issues/946) β€” bot doesn't check for new changes -- [changesets#1242](https://github.com/changesets/changesets/issues/1242) β€” bot/action version upgrade issues -- [changesets#43](https://github.com/changesets/changesets/issues/43) β€” can't customize bot messages - -### Prerelease channels that actually work - -Changesets' prerelease mode is described in their own docs as "very complicated" with "mistakes that can lead to repository and publish states that are very hard to fix." Key problems: global mode state poisons unrelated merges, exiting pre bumps ALL packages, counters require committed state, dist-tags can't be controlled. - -Bumpy replaces the mode with **branch-based channels** ([docs/prereleases.md](./prereleases.md)): a long-lived branch (e.g. `next`) maps to a prerelease line. Bump file location (`.bumpy//`) is the only state; prerelease versions are never committed β€” targets derive from bump files, counters from the registry. Promotion to stable is just a merge. - -- [changesets#729](https://github.com/changesets/changesets/issues/729) β€” exiting pre mode bumps all versions (14 comments) -- [changesets#786](https://github.com/changesets/changesets/issues/786) β€” can't control dist-tag in pre mode (13 comments) -- [changesets#635](https://github.com/changesets/changesets/issues/635) β€” prerelease workflow problems -- [changesets#239](https://github.com/changesets/changesets/issues/239) β€” prerelease mode design issues -- [changesets#381](https://github.com/changesets/changesets/issues/381) β€” prerelease counters require committed state - -### Local bump file verification - -`bumpy check` verifies that changed packages on the current branch have corresponding bump files. Compares your branch to the base branch, maps changed files to packages. By default it only fails if no bump files exist at all (matching changesets behavior). Use `--strict` to require every changed package to be covered, `--no-fail` for advisory-only mode, or `--hook pre-commit`/`--hook pre-push` to control which bump files count based on their git status. No GitHub API needed. - -Changesets has no built-in equivalent β€” users rely on the CI bot comment to catch missing bump files after pushing. - --- ## Planned / Not Yet Implemented @@ -192,6 +163,20 @@ Support for hotfixing older major versions on release branches. --- +## Fixed in changesets v3 + +For the record β€” these were long-standing v2 pain points that bumpy addressed and this doc used to track. Changesets v3 fixed them: + +- **Forced major bumps from peer deps** β€” v3 bumps peer dependents by patch instead of major (closed [#1011](https://github.com/changesets/changesets/issues/1011), [#822](https://github.com/changesets/changesets/issues/822), [#1126](https://github.com/changesets/changesets/issues/1126), [#1228](https://github.com/changesets/changesets/issues/1228), [#827](https://github.com/changesets/changesets/issues/827), [#960](https://github.com/changesets/changesets/issues/960), [#1735](https://github.com/changesets/changesets/issues/1735)). Still hardcoded β€” see [propagation](#configurable-dependency-bump-propagation) above. +- **`workspace:` ranges published unresolved** β€” v3 routes publishes through npm/pnpm/Yarn Berry CLIs (closed [#432](https://github.com/changesets/changesets/issues/432), [#1290](https://github.com/changesets/changesets/issues/1290), [#1421](https://github.com/changesets/changesets/issues/1421), [#1229](https://github.com/changesets/changesets/issues/1229), [#1454](https://github.com/changesets/changesets/issues/1454)). `catalog:` is still open. +- **Non-interactive `add`** β€” `--major`/`--minor`/`--patch` flags (comma-separated values supported), `-m` for the summary, and the confirmation prompt was removed (closed [#979](https://github.com/changesets/changesets/issues/979)). +- **Publish order & robustness** β€” releases are ordered in dependency-aware chunks (closed [#238](https://github.com/changesets/changesets/issues/238)); per-package error reporting, successful publishes get tagged even when another package fails, and auth retries no longer republish completed packages. +- **Provenance** β€” [#1152](https://github.com/changesets/changesets/issues/1152) closed via npm trusted publishing (OIDC provides provenance automatically); `changesets/action@v2` is trusted-publishing-first. +- **Infinite loops** β€” the `version` infinite loop (closed [#571](https://github.com/changesets/changesets/issues/571)) and a git-failure loop were fixed. +- **Misc:** `version` now exits 1 when there are no changesets (CI-friendly); private packages are no longer versioned by default; machine-readable output (`--output` JSON on `status`/`publish-plan`, NDJSON via `CHANGESETS_OUTPUT` for `publish`/`git-tag`); new `pack`/`publish-plan` commands; ESM-only with Node β‰₯22.11 and Yarn Classic support dropped. + +--- + ## Changesets bugs we avoid by design ### "Does master exist?" CI failures @@ -199,9 +184,3 @@ Support for hotfixing older major versions on release branches. Bumpy doesn't shell out to git for branch comparisons during normal operations. - [changesets#517](https://github.com/changesets/changesets/issues/517) β€” git failures in CI (41 comments) - -### Infinite loop in version command - -Bumpy's iterative propagation has a hard iteration cap. - -- [changesets#571](https://github.com/changesets/changesets/issues/571) β€” infinite loop in changeset version (21 comments) diff --git a/docs/prereleases.md b/docs/prereleases.md index b57c033..3777c81 100644 --- a/docs/prereleases.md +++ b/docs/prereleases.md @@ -289,7 +289,7 @@ This means **every prerelease of an upstream package breaks every dependent's ra ### The cycle moves as one -Because nothing is committed incrementally, **every publish recomputes the entire cycle from scratch** β€” all bump files, full propagation ([Phase A/B/C](./version-propagation.md) run unchanged, with proportional bump levels: `patch` for `dependencies`, match-the-trigger for `peerDependencies`, avoiding the changesets [#960](https://github.com/changesets/changesets/issues/960) force-major problem). Every in-cycle package gets a fresh counter and republishes together, every rc. +Because nothing is committed incrementally, **every publish recomputes the entire cycle from scratch** β€” all bump files, full propagation ([Phase A/B/C](./version-propagation.md) run unchanged, with proportional bump levels: `patch` for `dependencies`, match-the-trigger for `peerDependencies` β€” avoiding both the changesets v2 force-major problem ([#960](https://github.com/changesets/changesets/issues/960)) and the v3 always-patch assumption). Every in-cycle package gets a fresh counter and republishes together, every rc. This lockstep isn't a special rule β€” it falls out of "there is no incremental state." And it's what makes the coherence guarantee real: @@ -406,14 +406,14 @@ The directory used to hold shipped bump files matches the channel name: `.bumpy/ | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Entering | `changeset pre enter beta` writes `.changeset/pre.json` | Push to the channel branch | | Exiting | `changeset pre exit` + `version` + `publish` + delete `pre.json` | Merge channel branch β†’ main; the ordinary stable flow consumes the cycle | -| State file | `.changeset/pre.json` committed to repo | None β€” bump file location in `.bumpy/` is the only state | +| State file | `.changeset/pre.json` committed to repo (v3 moved versioned changesets to a `.changeset/pre/` folder, but the committed mode file remains) | None β€” bump file location in `.bumpy/` is the only state | | Prerelease versions in git | Committed to every `package.json` on every prerelease | Never β€” registry and tags only; `package.json` stays at the last stable version | | Wrong-branch hazard | Merging while pre mode is active accidentally turns stable releases into prereleases ([#239](https://github.com/changesets/changesets/issues/239)) | Impossible β€” channel state lives in the branch and the file layout, not in a global mode | | Dist-tag control | Locked to mode tag, `--tag` is rejected ([#786](https://github.com/changesets/changesets/issues/786)) | Per-channel `tag` config, independent of suffix | -| Dependent force-bumping | Cascades to **major** on peer deps by default ([#960](https://github.com/changesets/changesets/issues/960)) | Cascades at **proportional levels**; full cycle republishes each rc with exact-pinned inter-cycle deps β€” always a coherent set | +| Dependent force-bumping | Hardcoded: **major** on peer deps in v2 ([#960](https://github.com/changesets/changesets/issues/960)), always **patch** in v3 | Cascades at **proportional levels**; full cycle republishes each rc with exact-pinned inter-cycle deps β€” always a coherent set | | Counter | Requires committed `package.json` increments ([#381](https://github.com/changesets/changesets/issues/381)) | Derived from the registry (max published + 1); immune to resets and abandoned cycles | | Exit re-bumps everything | Yes ([#729](https://github.com/changesets/changesets/issues/729)) | No β€” promotion is an ordinary stable bump; there's no suffix to strip because none was committed | -| First publish during pre mode | Silently goes to `@latest` | Always goes to channel's dist-tag | +| First publish during pre mode | Goes to `@latest` on npm (the registry auto-assigns it; v3 only fixes registries that don't) | Always goes to channel's dist-tag | | Stable changelog after prereleases | Lossy β€” only the `pre exit` step's diff | Lossless β€” consolidated entry built from every bump file in the cycle | ---