Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 14 · LESSON 14.3

Upgrade and maintain the guide's app

Keep packages, schemas, examples and references aligned as FabrCore evolves.

Lesson 86 of 86 · FabrCore 2.0

Overview

The guide targets 2.0. Older examples may use retired packages, user-named compatibility APIs or outdated configuration placement. Framework development skills help maintain code; runtime skills change the agent's instructions. They are different release artifacts.

Version alignment includes more than NuGet

Host, SDK, agent code, database schema and configuration examples must target a compatible release. Development skills help update source, while runtime skill packages change agent instructions and have their own exact-version assignments. Updating one artifact should not silently imply the others are compatible.

Use the same checks to measure the upgrade

Read the migration reference for the versions actually involved and retain backups/recovery material before state changes. Rebuild the examples your product uses, then run deterministic, infrastructure and quality checks appropriate to its enabled features. Source availability does not prove a stable package version has been published to your feed.

Upgrade with a recorded baseline

  1. Follow /docs/upgrade-2-0 for matching packages and migration steps from 1.6, 1.7 or 1.8. Restore-test persisted state and migrate ACL data through supported paths.
  2. Pin the application's package baseline, rebuild its examples and rerun relevant deterministic/integration/evaluation checks after changes.
  3. Check public reference links after website publication and version changes. Keep configuration defaults and live/restart semantics synchronized with their actual consumers.
2.0.md · reference snippet 
{
  "ConnectionStrings": { "FabrCore": "<SQL connection from secret source>" },
  "FabrCore": { "Database": { "AutoInitialize": true } }
}
2.0.md · reference snippet 
options.ConfigureOrleans(silo => silo.Services.Configure<
    Orleans.Serialization.Configuration.TypeManifestOptions>(manifest =>
        manifest.AddAllowedType(typeof(MyPersistedType))));

Compare the upgraded application with its baseline

  1. Record the current package/schema/runtime-skill baseline and the last passing checks. Follow the release migration steps in staging with matching available packages.
  2. Re-run the same fixture request, persistence recovery and enabled integration checks. Compare model/tool attribution and evidence of behavior with the pre-upgrade record.
  3. Inspect every failed or skipped check and document its cause before rollout. Verify reference links and sample commands against the published version you intend readers to use.

The result is a supported upgrade decision with reproducible evidence. A successful compile is necessary, but it cannot alone establish data compatibility or unchanged agent behavior.

If the result is different

Do not infer package publication from source availability. If stable packages are unavailable, use the source workflow or a matching available prerelease set.

Go deeper

Explore the related documentation.