Versions and support

This page states what Mica promises from version 1.0: which parts follow semantic versioning, how a part goes away, which versions get fixes, and which other software Mica supports.

Mica is experimental and not ready for production. Before 1.0, a minor version can break each part on this page, and the changelog says how. Pin the versions.

Semantic versioning

From 1.0, Mica follows Semantic Versioning. All packages and the image have one version.

• A patch version fixes defects.
• A minor version adds features. It does not break a covered part.
• A major version can break a covered part. The changelog says how to upgrade.

The covered parts

The repository has an API report for each public entry point of the two packages. A change to a report is always a decision in a pull request.

The internal parts

These parts can change in any release. Do not depend on them:

• The HTTP routes of the editor (/api/admin/*, /api/auth/*) and their answers. Agents use the MCP tools.
• The names of the cookies.
• The packages @micacms/runtime and @micacms/mcp, and @micacms/core/internal. The editor installs them; they are not for your own code.
• The files in the data volume. The volume as a whole, its mount point and its layout version are covered.
• The words of messages and log lines.

Image tags

Each release has the image ghcr.io/micacms/mica:X.Y.Z. latest is the newest release, never a pre-release. Pin a version in compose.yml, so that an upgrade is your decision.

When a part goes away

1. A minor version deprecates the part. The changelog has a "Deprecated" section, and Mica shows a warning when you use the part.
2. The part goes away only in the next major version.

Which versions get fixes

• Fixes, security fixes included, go into the next release of the latest 1.x minor version. An earlier minor version gets no fixes: the upgrade inside 1.x is the fix, and it breaks no covered part.
• 0.x ends when 1.0 ships. A 0.x version gets no more fixes.
• Before 1.0, a change of the content format or of an API comes with no migration. Change your content by hand, or start again from the current shape.
• When 2.0 ships, its release notes say how long 1.x gets fixes.

The image and @micacms/astro

Your website's build uses @micacms/astro, which writes the manifest. The image reads it. The two can have different versions:

• The image reads each manifest with its protocol version. A new protocol version comes only with a major version.
• When the manifest has a field kind or an option that the image does not know, the image still starts. That collection or settings page is read-only until you upgrade the image, and the editor says why.
• So upgrade the image first, or at the same time as @micacms/astro. An older @micacms/astro with a newer image of the same major version always works.

The local editor installs its own version. Keep @micacms/editor and @micacms/astro at the same version in your project.

Supported versions

Mica supports only what CI tests.