Skip to main content

Release Strategy

Vortex packages follow semantic versioning, so the version number tells you what an upgrade involves.

Versioning

ReleaseIncludesUpgrading
MajorBreaking changes to APIs, names, or visualsMay need code changes; follow the migration guide
MinorNew features and improvementsNo code changes
PatchBug fixesNo code changes

Until 1.0, minor releases may include breaking changes, each with migration notes. Patch releases never do.

Packages

Each package is versioned and released on its own:

  • @vortexlabs/vortex: components, primitives, and hooks.
  • @vortexlabs/vortex-themes: theme generation and bundled themes.
  • @vortexlabs/vortex-icons: icons.
  • @vortexlabs/vortex-spinners: spinners.

Release phases

PhaseMeaning
BetaReady to use. The API may still change in minor releases based on feedback.
StableFollows the versioning rules above.
DeprecatedStill works but will be removed. Switch to the recommended replacement.

A component is Stable unless its documentation says otherwise.

Deprecations

Before an API is removed:

  • It's marked @deprecated, so your editor flags it and names the replacement.
  • The changelog announces it with migration steps.
  • It's removed in a later major release, or before 1.0, a later minor release.

Canary releases

Canary builds preview upcoming changes before they're released. They're published under the canary tag, so a regular install never picks them up:

bun add @vortexlabs/vortex@canary

The same tag works for vortex-themes, vortex-icons, and vortex-spinners. Use canary builds for testing, not production.

Stay up to date

Read the changelog for each release and its migration notes, and the roadmap for what's planned.