Maintain the repository#

Keep changes small enough to trace from an observable example to their implementation and checks. The architecture guide maps ownership; make repo-check enforces dependency boundaries, embedded implementation sources, syntax handling, and release triggers. Update its policy only when the dependency is intentional and explain that choice in the PR.

Refresh pinned inputs#

Use the checkout SDK for maintenance commands. Make uses the checkout SDK and prepares the mandatory embedded build payload. Commands below deliberately modify tracked inputs; make verify only checks them.

Dependabot groups weekly Go, extension, and Actions updates into reviewable PRs. Updates receive the same verification as other changes and are not automatically merged. Preserve vendor notices and run the relevant native/packaged checks before merging dependency changes. Review SDK statements in the implementation guide when changing the Go pin.

Public compatibility#

Treat Manuscript syntax and standard signatures, exported frontend Go APIs, CLI flags/statuses, diagnostic codes and JSON schemas, project configuration, and artifact metadata as contracts. Correcting diagnostic prose may change wording while retaining the code’s meaning. Internal package structure and generated Go identifiers are implementation details, except where the debugger’s checked metadata exposes a mapping.

Before 1.0, an intentional incompatible public change belongs in a minor release; patch releases contain compatible fixes. From 1.0 onward, incompatible changes require a major release. State the affected source or command and its migration in the PR and changelog. For a deprecation, document the replacement and intended removal release, and test both during the transition. Explicit user-directed removals take precedence; this policy does not restore retired APIs.

Build pins are intentionally strict: compiler/runtime/target changes can require ms lock even without a source-language compatibility change. Do not claim native binary reproducibility across environments or compatibility for undocumented internal layouts.

Prepare a release#

1. Describe user-visible changes and migrations under Unreleased in the root changelog .
2. Run toolchain/go/bin/go run ./scripts/maintenance version 0.1.1, substituting the release version. It moves the changelog entries under that version and updates .msversion. The CLI, build pins, and book read this single version.
3. Run make verify-full, extension packaging/debugger checks, and review the six-target distribution workflow. Refresh example pins when compiler inputs change.
4. Merge the release changes, then create the matching v<version> tag. Tagging publishes only after all six packaged binaries pass standalone verification. Use the changelog and migration notes when reviewing GitHub’s generated release notes.

A version update does not create a tag or publish anything. Documentation archives are separate preserved sites; adding a dropdown entry does not create an archive.

Keep the feedback loop healthy#

Use make verify while editing and make verify-full before merging changes that reach native behavior. CI runs fast checks first, then conformance, races, fuzzing, host matrices, editor/debugger integration, and release verification. The stable Language checks / test gate fails if any dependency job fails or is cancelled.

Add tests at the boundary where a regression is observable. Use source acceptance/rejection and transcripts for language changes; use barriers and channels for lifecycle ordering; use the packaged binary for installation claims. Coverage includes dependency packages but excludes execution inside separately built native programs. Treat low coverage as a prompt to inspect missing behavior, not as a reason to add tests that mirror implementation.