# Stability and versioning C+ keeps a **deliberately small language surface**. New capability goes into packages and tooling, not the core, so the language you read — and a model generates — stays small and predictable. The core itself does still change: to fix soundness and correctness bugs, and, more rarely, to refine syntax. Those changes ship only in **versioned releases**, and every release is archived. v0.0.23, for example, was a soundness and C-ABI hardening release that also refined the interface-impl syntax (`impl Type: Interface`, see [§9.3 of the specification](/docs/spec)). This page states what stays stable, what changes between releases, and how packages version on their own cadence. The [language specification](/docs/spec) is the normative description of the current surface. ## What stays stable - **A small surface.** The core stays small on purpose: types, ownership, the C ABI, and a little construction sugar. Capability grows by adding packages, not by growing the language, so the grammar and keyword set you learn stay compact. - **Source compatibility is the goal.** A program the current compiler accepts is intended to keep compiling, with the same meaning, on later releases. When a release does change whether a program compiles — almost always a soundness fix that rejects a program that was never sound — it is called out as such, and the release it compiled under stays available as an archive. - **A stable, dated target for tools and agents.** The grammar, the `cpc query` / `cpc mcp` code graph, the [error codes](/docs/error-codes), and the `/llms.txt` snapshots describe a specific, archived release. Tooling built against a version has a fixed target, and a citation can name the version it was written against. ## What changes between releases - **Soundness and correctness fixes.** Where the compiler and the [specification](/docs/spec) disagree, one is corrected to match the other. That can mean a program that was wrongly accepted is later rejected, or one that was wrongly rejected later compiles. This is the bulk of a release like v0.0.23. - **Occasional surface refinements.** The language surface changes rarely and deliberately. When it does — like the v0.0.23 interface-impl order — it ships in a versioned release with the change documented, and the prior release stays archived at its own URL. - **Diagnostics.** Error and warning *wording*, spans, notes, and machine-applicable suggestions improve freely. The stable [error codes](/docs/error-codes) and their meanings are the contract; the exact message text is not. - **Performance and code generation.** Optimisation, codegen quality, and ABI lowering improve over time. The language asks for no runtime tax for its safety, and that work is ongoing. - **Tooling.** `cpc` subcommands (`build`, `check`, `run`, `test`, `fmt`, `doc`, `query`, `mcp`, `lsp`) and the editor surface evolve and gain features — this is where most ongoing work lands. - **Targets.** Support for additional [targets](/docs/targets) and cross-compilation back-ends can be added; adding a target does not change the language. - **The standard library and packages.** `stdlib` and every package under `vendor/` evolve on their own cadence (see below). ## The compiler is the authority The [specification](/docs/spec) is verified against `cpc` and its test suite, but where the two ever disagree the **compiler wins** — run `cpc check` or `cpc build` and trust the diagnostic. The in-repo test suite is the executable conformance record. If you find a case where the compiler and the spec disagree, that is a bug worth [reporting](https://github.com/netdur/cplus). ## Packages version independently The package-first model is what keeps the language small. Capability that another language would build into the core lives in a package here, and each package carries **its own version** and moves at its own pace: - A package declares its dependencies and their versions in `Cplus.toml` and is resolved under `vendor/`. See [Modules and packages](/docs/modules-and-packages) and the [package manager](/docs/package-manager). - A new package, or a new release of an existing one, adds capability without touching the language. It builds against the same small language surface. - This is the intended path for everything additive: UI builders, FFI bindings, numeric kernels, embedded peripherals. The [packages index](/docs/packages) lists what ships today. ## Documentation versioning The manual you are reading **tracks the current release**. Every release is also archived: older versions stay available at `/docs/{version}` and are **never removed or collapsed** — they are intentional archives, not stale pages. When you cite the manual, cite the version. `/docs` and `/llms.txt` are authoritative for the latest release (v0.0.24). For *why* the design is the way it is, see the [design FAQ](/docs/faq).