Library Development Standard

Purpose and applicability

Other code can depend on a library long before anyone documents which interfaces may change. LDS makes that consumer boundary explicit.

Libraries, crates, packages and SDKs whose primary surface is code consumed by other code; companion commands and services have separate standards.

How it works

Write the public API, runtime/toolchain limits, extension contracts and known consumers. Assign experimental, interface-stable, versioned or reference stability based on evidence. Define breaking changes and a versioning/migration policy appropriate to that level.

Outputs are the interface note, versioning policy, extension contract, consumer links and maintained change history. A speculative API remains experimental.

In practice

The canonical breaking-change simulation replaces find_by_status with find_by_lifecycle. Add the new entry point before removing the old one, and give consumers a named migration window.

ManifestQuery.Core → consumer application
0.3.0: find_by_status(status)
0.4.0: add find_by_lifecycle(state); deprecate old entry point
0.4.x: consumers migrate; old API remains
1.0.0: remove find_by_status; record migration

Interface note: public surface, stability, version policy, extension contracts, known consumers.
Consumer validation: required before real removal.

Adopt one part

Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.

1. Describe one exported function or extension point and identify its consumer.
2. Record the library’s actual stability, minimum runtime and breaking-change policy.
3. Test the consumer relationship before removing an interface; record the version change and migration evidence.

Sources and limits

The migration cycle is simulated and does not report a released library. A shared programming language does not determine the standard: code API uses LDS, command uses CTS, running service uses SIS.

These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.

• LDS/LDS.manifest.toml
• LDS/Adoption-Guide.md
• LDS/Validation-Checklist.md
• LDS/Library Development Standard.md
• LDS/templates/Library-Interface-Note.md
• LDS/examples/Breaking-Change-Cycle.md