Navet is currently in beta. Until the product contract is stable, use pre-1.0 semantic versioning.
- Current release line:
0.x - Current version:
0.1.0-beta.3 - Meaning: first structured beta milestone, third prerelease build in that milestone
Use semantic versioning with prerelease tags when needed:
0.x.yfor beta releases0.x.y-beta.nfor prerelease/beta candidates within a milestone1.0.0only when core behavior and compatibility are considered stable
Examples:
0.1.0-beta.10.1.0-beta.20.1.0-beta.30.1.00.1.10.2.0
patch:- bug fixes
- translation fixes
- docs-only corrections tied to a shipped release
- small visual polish without feature expansion
minor:- new cards
- new settings
- meaningful dashboard behavior changes
- new integrations or user-visible capabilities
prerelease:-beta.nfor builds that should be tested before the milestone is treated as the current baseline
major:- reserve for
1.0.0and later stable-breaking releases
- reserve for
package.jsonis the canonical app version- the in-app Settings -> Project screen reads the version from
package.jsonthrough app-version.ts
Recommended lightweight flow:
- Decide whether the change is
patch,minor, orbeta prerelease. - Bump
package.json. - If the release meaning changed, update this file.
- Tag the commit with
v<version>, for examplev0.1.0-beta.3. - Push the tag to GitHub to trigger .github/workflows/github-release.yml.
- If needed, manually run the container publish workflows for matching image tags.
- Tags matching
v*create a GitHub Release automatically. - Tags containing
-beta.,-alpha., or-rc.are published as GitHub prereleases. - Stable tags such as
v0.1.0are published as normal releases.
Move to 1.0.0 when:
- core dashboard flows are stable
- major card types and settings behavior are no longer changing in breaking ways
- import/export and persistence formats are considered durable
- language, theming, and interaction models are stable enough to support compatibility expectations