Publish all reference implementations to their language package registries

[brunoborges]

Goal

Publish the six reference implementations as independently installable packages while preserving the distinction between:

• Artifact version: 1.0.0-rc.2 for the first registry release.
• TOML Schema language version: 1.0.0 (still unreleased and not to be bumped by this work).

This is the coordination issue. Each implementation has a child issue that separates maintainer-only registry setup from repository implementation and release execution.

Proposed package identities

Implementation	Registry	Proposed identity	Current registry status (2026-08-19)
Java	Maven Central	org.tomlschema:tomlschema	Coordinates not found; org.tomlschema must be verified through tomlschema.org DNS
Go	Go module proxy / pkg.go.dev	tomlschema.org/go	Not indexed; tomlschema.org was not reachable during planning
.NET	NuGet.org	TomlSchema	Package ID not found
Python	PyPI	distribution tomlschema; import remains toml_schema	toml-schema is already owned by an unrelated project; tomlschema was not found
Rust	crates.io	crate tomlschema; library remains toml_schema; binary is tosd	toml-schema resolves to the existing unrelated toml_schema crate; tomlschema was not found
Node.js / TypeScript	npm	@tomlschema/tomlschema	Scoped package not found; maintainer must control the tomlschema npm organization/scope

Registry names are immutable or expensive to change. The Python and Rust fallback names require explicit maintainer approval before code changes or reservation attempts.

Release and security policy

• Use one dedicated GitHub Actions workflow and one protected GitHub environment per registry (maven-central, nuget, pypi, crates-io, npm). Go has no credentialed publish step but still needs an explicit release workflow or documented tag procedure.
• Restrict environments to the corresponding language-prefixed tags and require a maintainer approval where GitHub plan support allows it.
• Prefer OIDC trusted publishing for PyPI, npm, and crates.io when available. Use least-privilege, package-scoped, expiring secrets where a registry still requires credentials.
• Publish only from an existing, immutable tag after the implementation's normal tests and package-specific dry-run checks pass.
• Use distinct monorepo tags so existing spec and CLI releases are not triggered accidentally:
  • java-v1.0.0-rc.2
  • reference-implementations/go/v1.0.0-rc.2 (Go submodule tag format)
  • dotnet-v1.0.0-rc.2
  • python-v1.0.0-rc.2
  • rust-v1.0.0-rc.2
  • typescript-v1.0.0-rc.2
• Never rebuild a published version from another commit. Registry versions and tags are immutable.
• Keep package metadata, READMEs, installation snippets, repository URLs, license data, and artifact versions aligned.

Coordinated plan

Phase 1: maintainer prerequisites

Complete every Maintainer setup section in the child issues: approve the two fallback names, establish registry accounts/organizations, verify namespaces and domains, configure protected GitHub environments, and add trusted-publisher bindings or scoped credentials.

No publication workflow should be enabled until its exact repository/workflow/environment identity is registered with the corresponding package manager.

Phase 2: repository implementation

For each implementation:

1. Complete required and recommended package metadata.
2. Add deterministic package build and content inspection commands.
3. Add a dedicated tag-gated release workflow with minimal permissions.
4. Add a non-publishing dry-run path suitable for pull requests or manual dispatch.
5. Update implementation documentation with registry installation and versioning guidance.
6. Keep existing conformance tests as a release gate.

Phase 3: release candidate execution

1. Merge all package metadata and workflows.
2. Run all six reference-implementation test suites.
3. Build and inspect every publication artifact without publishing.
4. Create the six tags from the same reviewed commit.
5. Approve each protected publication job after checking its artifact summary.
6. Publish 1.0.0-rc.2; do not publish 1.0.0 until the language release occurs.

The tracks may execute independently once their own maintainer prerequisites are complete, but this coordination issue remains open until all six are published and verified.

Phase 4: registry verification and documentation

For every package, verify from a clean environment that:

• the registry shows the intended owner, source repository, license, README/docs, and exact version;
• installation resolves from the public registry, not a local checkout or cache;
• the smallest documented validation example executes successfully;
• the published artifact contains only intended files;
• provenance/attestations appear where supported.

Then update README.md, REFERENCE_IMPLEMENTATIONS.md, and implementation READMEs with registry links, install commands, tag conventions, and release ownership.

Completion criteria

• Java package is available from Maven Central and resolves in a clean Maven project.
• Go module version is available through proxy.golang.org and documented on pkg.go.dev.
• .NET package is available from NuGet.org and restores in a clean project.
• Python distribution is available from PyPI and imports as toml_schema in a clean virtual environment.
• Rust crate installs from crates.io, exposes library toml_schema, and installs binary tosd.
• TypeScript package installs from npm with its ESM entry point and declarations intact.
• Registry URLs and installation commands are documented.
• Release credentials/trusted publishers and maintainer ownership are documented privately in the project’s operational records.

References

• GitHub Actions deployment environments
• Maven Central namespace registration
• pkg.go.dev: adding a package
• NuGet.org package publishing
• PyPI trusted publishers
• Cargo publishing
• npm trusted publishers

Child issues

• Publish the Java reference implementation to Maven Central #133 — Java / Maven Central
• Publish the Go reference implementation through pkg.go.dev #135 — Go module proxy and pkg.go.dev
• Publish the .NET reference implementation to NuGet.org #134 — .NET / NuGet.org
• Publish the Python reference implementation to PyPI #131 — Python / PyPI
• Publish the Rust library to crates.io #132 — Rust library / crates.io
• Publish and distribute the tosd CLI #139 — tosd CLI / Cargo install and GitHub Release assets
• Publish the TypeScript reference implementation to npm #130 — Node.js / TypeScript / npm