Section 17: Language Versioning and Evolution¶

TECHSPEC-17 — Section 17 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Evolution Philosophy¶

The language must evolve without sacrificing reliability or predictable behavior.

Changes must be deliberate, documented, versioned, and evaluated for their effect on existing programs.

Convenience must not justify silently weakening established guarantees.

2. Language Versioning¶

The language follows semantic versioning:

MAJOR: Introduces breaking changes to syntax, semantics, or compatibility guarantees.
MINOR: Adds backward-compatible language features.
PATCH: Corrects defects without intentionally changing established language behavior.

Rules: - Every source project must identify its language version. - Every compiler must identify the language versions it supports. - A compiler must not silently reinterpret source code under different language rules. - Version compatibility must be checked before compilation. - Deprecated features must remain documented.

3. Compiler Versioning¶

Compiler versions must be recorded independently from language versions.

Rules: - Compiler releases must identify supported language versions. - Compiler changes must document relevant behavior changes. - Verification evidence must identify the exact compiler and verifier versions. - A compiler update must not automatically inherit verification claims from an earlier version. - Compiler defects affecting correctness or verification must be disclosed and addressed.

4. Compatibility¶

Compatibility must be evaluated across:

Source syntax.
Type behavior.
Function contracts.
Public module interfaces.
Runtime behavior.
Standard library APIs.
Dependency requirements.
Verification evidence.

Rules: - Compatibility must not be inferred from successful compilation alone. - Behavioral changes must be documented. - Breaking changes must require an explicit migration. - Existing projects must not silently adopt new semantics.

5. Language Change Proposals¶

Significant language changes must have a documented proposal.

Each proposal must include: - Problem being addressed. - Proposed change. - Motivation. - Syntax and semantic definitions. - Compatibility impact. - Security and reliability impact. - Compiler implementation requirements. - Testing requirements. - Verification implications. - Migration strategy.

Proposals must be evaluated before becoming part of the language specification.

6. Deprecation and Migration¶

Features may be deprecated when a safer or more consistent alternative exists.

Rules: - Deprecation must be documented. - Warnings must identify the affected feature. - Migration guidance must be provided. - Automated migration tools must preserve program behavior where that can be established. - Uncertain migrations must be reported rather than silently applied. - Removed features require a major version change.

7. Verification Across Versions¶

Verification evidence must remain tied to the exact versions under which it was produced.

Rules: - Language changes must trigger evaluation of affected verification evidence. - Compiler changes must trigger re-evaluation when relevant compiler behavior changes. - Verifier changes must identify any changes in proof or analysis guarantees. - Old evidence must remain identifiable. - Stale evidence must never be presented as current verification.

8. Compiler and Ecosystem Responsibilities¶

The language ecosystem must: - Maintain versioned specifications. - Track compiler compatibility. - Document breaking changes. - Provide migration guidance. - Preserve historical verification records. - Identify incompatible dependencies. - Report stale or invalidated evidence.

9. Design Goal¶

The language must improve without creating uncertainty about what existing programs mean or what their verification results establish.

Every change must have a traceable history and an explicitly defined compatibility impact.

Source file: TECHSPEC-17.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.