Versioning and support policy

• Each SDK follows Semantic Versioning 2.0. A major release may break; a minor release adds features, packages, platforms and deprecations; a patch release only fixes.
• All packages of one SDK share its version.
• Previews of the next version (x.y.0-preview.N) go to the npm preview dist-tag; latest moves only to stable versions.
• Experimental APIs and the preview package are outside these rules.

A change is breaking when a project that built and ran against a release fails to build, fails to run or behaves differently against a later minor or patch of the same major without changes by its author. That covers:

• The C# API in each library's PublicAPI.Shipped.txt: removed or renamed members, changed signatures, nullability or defaults, new abstract or interface members without a default, sealed types, changed documented behaviour or failure results.
• New trim or AOT warnings in an AOT-compatible library.
• Diagnostic IDs reused for another meaning, or warnings turned into errors.
• Documented MSBuild properties, items and targets, and defaults that change a passing build. Renamed properties keep working with a warning.
• Command-line commands, options, exit codes and versioned JSON contracts such as runic.create/1 or runic.commandline/1. A changed contract gets a new identifier and the old one stays until the next major. Human-readable output is not a contract.
• The Bridge protocol between .NET and npm packages of the same release, and the Translations transport: a 1.x reader reads every message a 1.x writer produced.
• npm exports, TypeScript types and peer ranges; widening a range is not breaking.
• Dropping a supported RID, host or OS version before .NET drops it, and dependency updates that change third-party types in the public API (ReactiveUI, Spectre.Console, CS-WebUI).

Every shipping library tracks its API with the public API analyzers and runs package validation against the latest stable release of its major line. Compatibility suppressions are allowed only in a major release, for experimental members, or for a security fix that the release notes explain. A stable package never depends on a prerelease package.

1.0.0 ships as one release train in dependency order: Command Line, then Translations, then Runic SDK. After 1.0 each SDK releases minors and patches independently, references the others by NuGet minimum version, and names in its release notes the versions it was tested with.

A host and RID pair is supported only when Runic CI builds and runs that host's native layer on it. Packaged but unverified RIDs are best effort. The supported platforms page shows the current status and minimum operating systems. The planned 1.0 status, with the RIDs that move into CI during 0.9:

Runic.Platform.Administration.Windows supports Windows x64 only. Managed packages and Command Line apps run wherever .NET 10 does; Command Line NativeAOT apps are supported on the RIDs its CI publishes. On musl, Runic Desktop needs an Alpine release that .NET 10 supports, with GTK 3 and WebKitGTK 4.1.

Every package targets net10.0 (WPF packages net10.0-windows); .NET 10 is supported by Microsoft until November 2028. Later .NET versions use the net10.0 assets. Adding a target framework is a minor release; dropping a .NET version needs a major release, and net10.0 is not dropped before .NET 10 leaves support.

• Stable: every shipped package from 1.0.0.
• Experimental APIs in stable packages: marked [Experimental] with one diagnostic ID per API family. Use is a compile error until the project suppresses the ID, and the API may change in a minor release. The IDs are listed on the experimental APIs page.
• Preview: Runic.Application.Views.CsWebUi is the only preview package. It ships with each stable release on a prerelease version and may change in any release.

• Deprecated APIs get [Obsolete] with a diagnostic ID and the replacement, stay for at least one minor release, and are removed only in a major release. Each deprecation has a release-notes entry.
• Bug and security fixes ship in a patch of the latest minor only. A preview gets no fixes once the next release ships.

Each SDK's release guide holds the full policy and its own rules:

• Runic SDK
• Runic Command Line
• Runic Translations