Packages and versions

What a site actually references

A site restores the libraries, not the template. Cendia.Templates is a dotnet new shim and is in no site's dependency graph — it delivers the starting files and then plays no further part.

A site names one package, Cendia.CMS. It is all of Cendia, and it brings the rest with it:

Coming from 1.0

Up to 1.0, Cendia.Captcha.Turnstile was a separate package: a site that used it referenced it and called builder.Services.AddCendiaTurnstile(). From 1.1 it comes with Cendia.CMS and AddCendia registers it. Remove the package reference when you update; leaving it in holds it at the old version, and NuGet then refuses to update Cendia.CMS (NU1605). The AddCendiaTurnstile() call can stay or go; it is no longer needed.

What you type

Package names are not what goes after using. Whichever package a type lives in, its namespace says what it is and nothing about how Cendia is assembled:

using Cendia;             // AddCendia, MapCendia, CendiaOptions
using Cendia.Schema;      // [ContentTypeId], PageType, BlockType, field attributes
using Cendia.FieldTypes;  // HtmlString, ContentReference, ContentZone
using Cendia.Content;
using Cendia.Rendering;
using Cendia.Data;        // CmsDbContext

What you update

A site made from the Starter names Cendia.CMS in its project file, at the exact version of the release it was made from. Everything else arrives with it at the same version.

Nothing updates a site for you. To move to a newer release, or back to an older one, change that one version: in Visual Studio's Manage NuGet Packages with the package source set to the Cendia feed (https://nuget.cendia.com/index.json) or to All, or with dotnet add package Cendia.CMS --version <version>. The feed's own page lists every release.

If you add a direct reference to another Cendia package, Cendia.UI for instance, update it first or together with Cendia.CMS. NuGet will not move Cendia.CMS past a Cendia package the site holds at an older version; it reports a package downgrade (NU1605) and changes nothing.

Coming from 0.7

Releases up to 0.7.2 named the package Cendia.AspNetCore, with Cendia.SchemaGenerator (and, in the Starter, Cendia.UI) beside it, and put Core or AspNetCore in the middle of every namespace. To bring a 0.7 site forward:

1. In the project file, replace the Cendia.AspNetCore, Cendia.UI and Cendia.SchemaGenerator references with one: <PackageReference Include="Cendia.CMS" Version="..." />. Do not keep Cendia.SchemaGenerator: the generator ships inside Cendia.CMS now, and the old one does not know the new names.
2. In the code, take Core. and AspNetCore. out of the Cendia namespaces: Cendia.Core.Schema and Cendia.AspNetCore.Schema are both Cendia.Schema, Cendia.AspNetCore.Rendering is Cendia.Rendering, and using Cendia.AspNetCore; is using Cendia;. One exception: what was Cendia.Core.SystemFields is now Cendia.Content.
3. If appsettings.json sets a log level for a Cendia category by name, rename it the same way.

Nothing in the database changes. The platform's own scheduled jobs keep their schedules and history under their new names.

The upgrade promise, and its limit

Package updates flow into an existing project. The scaffold does not.

That is the whole shape of an upgrade: you take new packages, and the files dotnet new gave you stay yours. It is also why the Starter is kept deliberately minimal — the promise holds only while the scaffold is small enough to have nothing that needs to flow.

If a release changes something in the scaffolded files, that is an upgrade note, and it will say so in words rather than expecting you to diff a template.

The generator is a build-time dependency

Cendia.CMS carries a source generator as an analyzer. It emits descriptors for your content types at build time; it is not part of what your site ships.

Where announcements live

Release announcements and upgrade notes are CMS content on this site, not files in this section — see Releases. This section covers the mechanics that do not change between releases; what changed in a given version is published as an announcement, with a date on it.

The split is deliberate, and it is the same one the whole site runs on: a guide describes code, so it lives in the repo and changes in the same commit as the code it documents. An announcement is editorial and dated — written once, never revised — so it is authored in the CMS, where scheduling and a publishing workflow are worth having.