Each release page is a record rather than an announcement: what shipped, what it corrected,
and what was deliberately deferred. The reasoning is included because a release note that
only lists features cannot be checked.

| Version | Released | Headline |
| --- | --- | --- |
| [Latest](/releases/latest) | 2.6.0 | Native components are styled again, and the renderer ships its Tailwind preset |
| [2.0.0](/releases/2.0.0) | 2.0 | The layout system, the native component set, and three corrections |
| [1.1.0](/releases/1.1.0) | 1.1 | The Puck integration, and the components added beside it |
| [1.0.0](/releases/1.0.0) | 1.0 | The first release |

## How versions work

The packages version independently, because they are released independently: a fix in a web renderer does
not need a CLI release. Each package states its siblings as a caret range, so `@asheeui/web@2.5.0` requires
`@asheeui/core@^2.3.1` and is installed alongside whatever minor of core that resolves to.

Two consequences are worth knowing before pinning:

- **A minor release can reach you without a change to your own manifest.** `asheeui@2.2.1` accepts
  `@asheeui/web@^2.3.0`, so a fresh install resolves the newest web minor. If you need a fixed pair, pin
  the packages you import rather than the umbrella.
- **The umbrella follows the renderers rather than leading them.** `asheeui` exists so an application can
  depend on one package; its own version can trail the renderers it names, and the table on
  [the latest release](/releases/latest) is the authority on what each package publishes.

`@asheeui/cli` went to `1.0.0` when the `playground` command was removed: a breaking change for a 0.x
package is a major bump, and that release also states that the command line's surface is stable.

Between releases, the [migration guide](/migration) records every breaking change and the
path from the version that had it.