Registering a Package

Registering a package

This page is the practitioner-facing companion to GOVERNANCE.adoc. The governance file states the policy; this page walks through the mechanics.

When to register

Register a package here when:

• It is part of the hyperpolymath ecosystem (or a tightly coupled dependency thereof).
• A vX.Y.Z git tag exists on the upstream repo.
• The package meets the quality bar below.

Do not register here packages that should live in JuliaRegistries/General — this registry is a proving ground and aggregator for the hyperpolymath surface, not a competitor to General.

Quality bar

A package must satisfy all of the following before registration is accepted:

Check	Detail
SPDX headers	Every source file carries an SPDX-License-Identifier: line
REUSE compliance	A LICENSES/ directory exists with the canonical license texts
License compatibility	Compatible with the registry's PMPL-1.0-or-later (or MPL-2.0-or-later equivalent)
OpenSSF Scorecard ≥ 7	Link the latest scorecard run in the registration PR
No banned-language files	No TypeScript, no npm/bun, no Go, no Python source files
compat ranges	Project.toml has semver [compat] entries for all [deps]
Upstream tag	A git tag matching vX.Y.Z exists on the upstream repo

How to register (step by step)

1. Open a registration issue (optional but encouraged)

Use the Package registration request issue template. This lets maintainers raise concerns before you spend time on the PR.

2. Create the directory structure

For a brand-new package Foo versioned 0.1.0:

F/Foo/
├── Package.toml
├── Versions.toml
├── Deps.toml
└── Compat.toml

For a new version of an existing package, append to Versions.toml / Deps.toml / Compat.toml without touching Package.toml.

3. Update Registry.toml

Add an entry for the package under the [packages] table (skip if updating an existing package — the entry already exists).

4. Open a PR

Branch name: feat/register-<package>-v<X.Y.Z> or for new packages feat/add-<package>-v<X.Y.Z>.

PR title: feat(registry): register <Package> v<X.Y.Z> (use add instead of register for the first version of a new package).

Use the PR template — fill in the registry-specific checklist boxes.

5. CI green + BDFL review

Once the workflows pass and the BDFL has reviewed against the quality bar, the PR is squash-merged. The package is then available via Pkg.Registry.update(); Pkg.add("Foo").

Updating an existing version

If you need to correct a published Versions.toml / Deps.toml / Compat.toml entry without bumping the version (e.g. typo in a dep), open an issue first — registry mutations on already-published versions are reviewed more carefully than new versions because downstream resolvers may have cached the old metadata.

Yanking a version

In rare cases (security incident, broken release) a version may need to be yanked. Open an issue tagged yank with:

• Package + version
• Reason
• Recommended replacement version (if any)

The BDFL handles yanks manually because they affect downstream resolvers globally.

Examples

The most recent registration PRs are good worked examples:

• PR #16 — register EchoTypes v0.1.0 + KRLAdapter v0.1.0 (in flight)
• Older registration PRs live on the closed-PR list.