Aeonav
  • Pricing
  • Changelog
  • Roadmap
  • Vision
  • Docs
GitHubSign up
IntroductionQuick Start
OverviewDevelopment SetupCommands ReferenceArchitectureConfigurationCloud DeploymentTelemetryAI Contribution PolicyVersioning & Releases
Edit this page·View as Markdown·Report an issue·Join our Discord

Get product updates

New features and releases from Aeonav, straight to your inbox.

Product

  • Features
  • Pricing
  • Off-Site AEO
  • Changelog
  • Roadmap

Resources

  • Blog
  • Documentation
  • Support
  • API Reference
  • Provider Status
  • Issues

Learn

  • What is AEO?
  • What is GEO?
  • AEO Glossary
  • AI Search Guides
  • AI Search Statistics
  • AEO by Industry

Tools

  • Tool Directory
  • Free & Open-Source Tools
  • Compare Tools

Company

  • About
  • Vision
  • Brand Assets
  • Contact
  • llms.txt

© 2026 Aeonav

TermsPrivacyCookiesSubprocessorsAcceptable Use
v0.7.8GitHub repositorysupport@fivecoder.com

Versioning & Releases

How Aeonav handles versioning, changesets, and the release process.

Changesets

Aeonav uses Changesets for version management. All packages in the monorepo use fixed versioning — they stay on the same version number.

Adding a Changeset

Every PR that changes user-facing behavior should include a changeset:

pnpm changeset

This interactive command asks:

  1. Which packages are affected
  2. Whether the change is a major, minor, or patch
  3. A short description of what changed

A markdown file is created in the .changeset/ directory. Commit this file with your PR.

What Needs a Changeset

  • Bug fixes → patch
  • New features → minor
  • Breaking changes → major
  • Documentation-only changes → usually don't need a changeset
  • Internal refactors that don't change behavior → usually don't need a changeset

Release Process (Maintainers)

When ready to release a new version:

  1. Apply changesets and bump versions locally:
    pnpm version-packages
    This consumes all pending changeset files, updates package.json versions across the monorepo, and generates CHANGELOG.md entries.
  2. Review and commit the version changes:
    git add .
    git commit -m "chore: release v$(node -p "require('./apps/cli/package.json').version")"
    git push
  3. Trigger the release workflow from GitHub Actions:
    • Go to Actions → Release → Run workflow
    • This creates a GitHub release and publishes to Docker Hub and npm

The Docker Hub token must be able to push repositories in the orbitrepos namespace. Configure the protected release environment with required reviewers so packages and images cannot be published without approval.

What Gets Published

ArtifactRegistryDescription
@elmohq/clinpmThe Aeonav CLI package
orbitrepos/aeonav-webDocker HubWeb app Docker image
orbitrepos/aeonav-workerDocker HubWorker Docker image
orbitrepos/aeonav-wwwDocker HubMarketing site Docker image
orbitrepos/aeonav-db-migrateDocker HubOne-shot drizzle migrations image

Each image is published with an immutable release version tag and a convenience latest tag. Production Compose files must pin complete @sha256: image digests from the release's image-references artifact. Tags, including version tags and latest, are mutable and must not be used as production deployment inputs.

Versioning Strategy

All packages share the same version number. When any package changes, all versions bump together. This keeps things simple and avoids compatibility issues between packages.

Was this page helpful?

On this page

ChangesetsAdding a ChangesetWhat Needs a ChangesetRelease Process (Maintainers)What Gets PublishedVersioning Strategy