Deployment
Release & Versioning
Semantic Versioning
Vextro follows semver. Currently at 0.x, minor versions may include breaking changes. The standard semver contract applies from 1.0.0.
| Increment | When |
|---|---|
| MAJOR | Breaking changes to public API, config shape, or CSS tokens |
| MINOR | New features, field types, hooks (backward compatible) |
| PATCH | Bug fixes, performance, documentation |
Changeset Workflow
Every change to a published package requires a Changeset.
pnpm changeset # create a changeset
pnpm changeset version # bump versions
pnpm changeset publish # publish to npmUpdating Vextro
pnpm update vextroPost-update: read the changelog, run npx vextro-migrate --check, rebuild, and test in both light and dark mode.
Breaking Changes Policy
| Phase | Duration | What Happens |
|---|---|---|
| Deprecation | At least 1 minor release | Old API marked with console warnings |
| Migration guide | Same release | Docs explain the upgrade path |
| Removal | Next major release | Deprecated API removed |
What Counts as Breaking
- Renaming or removing public exports (
createVextroClient,defineVextroCollection) - Changing
VextroConfigshape in a non-additive way - Renaming CSS custom properties or Tailwind utility classes
- Modifying Convex table names or required indexes in
vextroTables
What Is Not Breaking
- Adding new optional config fields or CSS tokens
- Adding new field types to the builder
- Internal refactors not affecting public API
Pinning Versions
In the 0.x phase, pin the exact version for stability:
{ "dependencies": { "vextro": "0.1.0" } }