Versions and support
Pluto is in alpha. This page tells you what each stage promises, how the packages are numbered, and what a breaking change gets.
The stages
| Stage | What it promises |
|---|---|
| Alpha | Features change fast. A release can break your app, with no note. |
| Beta | A public product, not a stable one. A full blog on both backends. A release can still break your app, but every breaking change gets a note in the changelog and the steps on the Upgrading page. |
| Release candidate | The candidates for 1.0. |
| 1.0 | Stable. |
Version numbers
Every package is 0.x until 1.0. Each package has its own number.
- A minor release (for example
0.66.0to0.67.0) adds features. It can also have a breaking change. - A patch release (for example
0.66.0to0.66.1) fixes bugs. It never has a breaking change.
| Package | What it is |
|---|---|
@plutocms/core | The admin, the content model, the Git CMS, and the public API. |
@plutocms/supabase | The Supabase backend. |
@plutocms/supabase-blog | The blog on Supabase. |
@plutocms/supabase-shop | The shop on Supabase. |
@plutocms/docs | The docs layer. |
@plutocms/seo | SEO fields, the sitemap, robots.txt, and the feed. |
@plutocms/shop | The cart and the shop helpers. |
@plutocms/3d | 3D models (.glb) in the media library, with a viewer. |
create-pluto | The CLI that makes a new project. |
How the packages fit together
A layer depends on another layer with a wide range, such as >=0.66.0 <1.0.0. One version of core works with every layer, so you can update one package at a time.
When a layer needs a newer core, it raises the lower bound of its range. Your package manager then installs the newer core with it.
Update the @plutocms packages of your app together, and read the Upgrading page before you update.
What is a breaking change
A breaking change is a change that can stop an app that uses the documented parts of Pluto. The documented parts are:
- The public API (
/api/pluto/v1). It has its own version: a breaking change of the API ships as a new version next to the old one. See Public API. - The composables, components, and utilities on these pages.
- The configuration keys and the module options on these pages.
- The content type definition. See Content model.
- The contracts for a layer: the content adapter, the drivers, and the extension registry. See Extend.
definePlutoBlockand the blocks of the visual editor.- The database migrations of the Supabase layers.
- The questions and the options of
create-pluto.
These parts are not public, and they can change in any release:
- The internal routes under
/api/_pluto/. The admin uses them. - The files, the names, and the options that these pages do not show.
- The layout of the admin.
What a breaking change gets
From the beta on, every breaking change gets:
- A ⚠ BREAKING CHANGES entry in the changelog of the package.
- A section on the Upgrading page, with the steps for your app.
The two come in the same release as the change. There is no deprecation period: the old API can go in the same release.
Changelogs
Each package has a changelog in its repository, and each release has a GitHub release:
@plutocms/core,@plutocms/docs, and the add-ons, in plutocms/pluto.@plutocms/supabase,@plutocms/supabase-blog, and@plutocms/supabase-shop, in plutocms/supabase.create-pluto, in plutocms/create-pluto.