beachball
Home
Getting started
GitHub
Home
Getting started
GitHub
  • Overview

    • Getting started
    • Installation
    • Configuration
  • Concepts

    • Bump algorithm
    • Change files
    • Change types
    • CI integration
    • Groups
  • CLI commands

    • Common options
    • bump
    • change
    • check
    • config
    • publish
    • sync

Change types

When running beachball change, you need to choose a change type that describes the impact of your changes. Beachball uses this to determine how to bump the package version.

The available types follow semantic versioning conventions.

Choosing a change type

Stable packages (version >= 1.0.0)

TypeWhen to useVersion bump
patchBug fixes or internal changes that don't affect exported API signatures1.0.0 → 1.0.1
minorNew exported APIs, non-breaking changes to exported API signatures, or significant changes to internal logic1.0.0 → 1.1.0
majorBreaking changes to exported APIs (removals or breaking signature changes), critical dependency updates, or behavior changes that could break consumers1.0.0 → 2.0.0
noneChanges that don't affect consumers at all (tests, documentation, internal config)no bump

When in doubt between minor/patch or patch/none, it's generally best to choose the larger change type.

Zero-version packages (version 0.x.y)

Packages with a major version of 0 are considered unstable per the semver spec. The conventions are slightly different:

TypeWhen to useVersion bump
patchAny non-breaking changes that affect consumers0.1.0 → 0.1.1
minorBreaking changes0.1.0 → 0.2.0
noneChanges that don't affect consumers at allno bump

Disallowed change types

Some repos or packages may restrict which change types are allowed using the disallowedChangeTypes config option. For example, major bumps are often disallowed to ensure coordination of major release efforts. Any disallowed options will be omitted from the interactive prompt, and a change file or --type argument that uses a disallowed type will cause an error.

Tips for reviewers

Change files show up as part of the PR diff, making it easy to verify the change type during code review. Common things to watch for:

  • A patch that should be minor because a new API was added
  • A minor that should be major because an existing API was changed in a breaking way
  • A none that should be patch because the change does affect published output
Last Updated: 3/28/26, 7:42 AM
Contributors: Elizabeth Craig
Prev
Change files
Next
CI integration