> ## Documentation Index
> Fetch the complete documentation index at: https://anvil.servicetitan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning and Releases

> Versioning and releases ensure teams stay aligned with updates to Anvil2 and can adopt changes consistently across products.

## How Versioning Works

Anvil2 uses semantic versioning, following the standard three-part version string:

`MAJOR.MINOR.PATCH`

### Major releases

Indicate breaking changes that may require design or engineering updates. Breaking changes to stable components and features are batched into major releases.

#### Examples

* Large UI changes affecting multiple components
* Significant updates to foundational tokens
* Removing previously deprecated components or features
* Major changes to API or behavior

Major releases are planned on a **quarterly cadence**. Announcements are shared approximately three months ahead of the target release window, giving teams time to plan for migration and testing. For major breaking changes, the Anvil team will provide migration guidance at time of release.

***

### Minor releases

Add new features while maintaining backwards compatibility. Minor releases ship **as needed** when feature work is ready.

#### Examples

* New components or variants
* Updated interactions
* Enhancements to patterns
* Additions to documentation
* Minor accessibility improvements

Teams can adopt minor releases immediately, as they do not break existing implementations.

***

### Patch releases

Contain small, safe, incremental updates. Patch releases ship **as needed**.

#### Examples

* Bug fixes
* Visual polish
* Icon additions
* Documentation corrections
* Minor accessibility fixes
* Internal code improvements

Teams should adopt patch releases as soon as possible to ensure quality and consistency.

<Info>
  Patch releases may also include breaking changes to **beta** features. See [Beta features](#beta-features) below.
</Info>

***

## Communications

### Per-release announcements

Every Anvil2 release triggers an announcement in [#ask-designsystem](https://servicetitan.enterprise.slack.com/archives/CBSRGHTRS) so teams can track what changed and when.

### Weekly changelog summary

A weekly batch summary of all Anvil2 package releases from the prior week is posted to [#dev](https://servicetitan.enterprise.slack.com/archives/CAXMG2939). This makes it easy for engineering teams to catch up on recent changes in one place.

### Major release announcements

Major release announcements are shared approximately **three months ahead** of the target release window. Initial communication goes to the Platform team for coordination, then is shared broadly in [#ask-designsystem](https://servicetitan.enterprise.slack.com/archives/CBSRGHTRS) and [#dev](https://servicetitan.enterprise.slack.com/archives/CAXMG2939).

***

## Beta features

Some components and features are released as **beta** before being stabilized. Beta releases allow teams to try new features in real products and provide feedback while we continue to iterate.

### What to expect from beta

* Beta features may change, including breaking API changes, **within patch releases**.
* Beta features are clearly marked in the changelog (prefixed with **BETA**) and in documentation.
* Stable APIs are never broken in patch releases — only APIs explicitly marked as beta may change incompatibly.

### When beta features graduate

Once a beta feature has enough production usage and feedback, it will be stabilized and follow standard semver guarantees from that point forward.

<Card title="Understanding Anvil2's Beta Features" icon="rss" href="/blog/posts/2026-01-28-understanding-beta-features">
  A deep dive into how beta features work, what the beta label means, and what to expect when adopting them.
</Card>

***

## Adopting Updates

To stay aligned with the system, teams should:

* Review [release notes](https://github.com/servicetitan/hammer/blob/main/packages/anvil2/CHANGELOG.md) when a new version is released
* Integrate minor and patch updates promptly
* Plan for major release migrations ahead of the release window
* Remove deprecated usage as part of ongoing maintenance
* Test UI behavior after upgrading the code package
* Report issues or ask questions in [#ask-designsystem](https://servicetitan.enterprise.slack.com/archives/CBSRGHTRS)

## Related

<Columns cols={2}>
  <Card title="Changelog" icon="list" href="https://github.com/servicetitan/hammer/blob/main/packages/anvil2/CHANGELOG.md">
    Full history of Anvil2 package releases and changes.
  </Card>

  <Card title="Roadmap" icon="map" href="/docs/resources/roadmap">
    See what the Anvil team is working on and what's coming next.
  </Card>
</Columns>