Publishing Rust crates

Publish library releases to crates.io. docs.rs builds their Rust API documentation automatically from the uploaded source and its rustdoc comments. The website continues to own tutorials, the language reference and interactive examples, and includes API docs for the current checkout.

See the Cargo publishing guide and docs.rs build documentation.

Release packages

These are the proposed initial release set. Retained application crates and repository tooling stay private. The workspace currently inherits publish = false; keep that default and opt individual release packages into publish = ["crates-io"] when preparing an approved release.

Local dependencies need both a path and a registry version:

konjure-sdk = { path = "../konjure-sdk", version = "0.1.0" }

Cargo uses the checkout locally and the registry version in the uploaded package. Keep those versions aligned when releasing dependent crates. Cargo dependency rules

Before the first release

The source audit on September 13, 2026 found two unresolved release decisions:

• License: the repository has no release license. Choose the license for the public libraries, add its text and set license or license-file in each released package. Do not infer licensing from third-party dependencies.
• Standalone tests: SDK tests include examples/sdk/*.kj outside their crate. These files are absent from the SDK package. Move the authoritative fixtures into the crate and update their repository consumers before release; an extracted archive must test without the surrounding monorepo.

Package README files and metadata describe the individual libraries. A package must contain every source, fixture and asset its build or tests require. Review the archive separately from the repository. The public source upload does not require publishing the retained applications or their private data.

The four crate names were unclaimed when checked on September 13, 2026. Names are allocated to the first publisher; check them again at release time.

Validate the release

Start from a clean commit and run the existing SDK, language and website gates:

bash scripts/check-sdk.sh
bash scripts/check-language.sh
npm run verify
npm run test:web

After resolving the license, fixtures and per-package publish settings, inspect and verify the first archive:

cargo package -p konjure-sdk --list
cargo publish -p konjure-sdk --dry-run

Extract the generated .crate archive outside the repository and run its tests, doctests and examples there. This catches accidental dependencies on workspace files that a library-only compilation can miss.

Repeat packaging for each dependent library after its required versions are available in the registry. A path dependency cannot substitute for an unpublished dependency when Cargo verifies the registry archive. Check the crate’s Rustdoc with warnings denied and its intended documentation features.

Publish and verify

The first publisher needs a crates.io account with a verified email address and publish credentials. Authenticate through Cargo; never commit credentials or put them in a website build. This guide does not authorize publication.

Publish the approved versions in dependency order, checking the dry run before each upload:

cargo publish -p konjure-sdk
cargo publish -p konjure-lang
cargo publish -p konjure-ffi
cargo publish -p konjure-wasm

Confirm the package version, contents and owners on crates.io, then check the docs.rs build and open representative modules, types and examples. A successful upload alone does not establish a successful documentation build. Record the release in the changelog and tag the exact source commit. After publication, link the website to the confirmed, versioned docs.rs pages.

docs.rs uses its own Rust toolchain and an isolated build environment. Use package.metadata.docs.rs when a crate needs specific features or targets documented. Keep examples and build scripts independent of local device SDKs, network services and monorepo-only files.

For later releases, configure crates.io trusted publishing for a dedicated GitHub release workflow after setting up crate ownership. It uses short-lived credentials. Keep package releases separate from the website deployment workflow.