Skip to content

Release the ecosystem in dependency order

Use this procedure for a coordinated release. Each package repository owns its version, changelog, tests, build workflow, and publication credentials; Spine owns the ordering and cross-repository verification.

Maintainer-operated procedure

Neither documentation CI nor Spine's checks execute a release. A maintainer runs this playbook deliberately, and every build, publication, tag, feedstock update, and downstream verification remains gated by the owning repository and its release credentials.

1. Establish scope and green state

python3 scripts/repo_state.py --include-spine --target main
python3 scripts/drift_scoreboard.py render --strict

Write down which packages, artifacts, and feedstocks are actually changing. Run the owning repository's full release checks and confirm that downstream minimum versions remain compatible. Do not publish from a dirty checkout.

2. Release ssm-simulators first

Follow the ssm-simulators release documentation to update its version and changelog, run its compiler-backed test matrix, create a v-prefixed tag, and publish the package. Verify the released artifact before updating consumers or its conda-forge feedstock.

3. Release LANfactory when needed

Confirm its declared ssm-simulators floor accepts the released producer, then run LANfactory's repository-owned release checks and publish it. LANfactory uses bare version tags such as 0.8.0, not v0.8.0.

Changes that only affect LANfactory do not require a simulator release, but a coordinated train still follows dependency order.

4. Build and validate network artifacts when warranted

LAN_pipeline_minimal owns the validated path from pinned simulator/trainer inputs through generation, training, validation, staging, and promotion. Use its rendered operator documentation and recorded run identity. Do not replace validation with an ad hoc upload command.

Publish a trained network only after the pipeline's validation and promotion gates pass. The artifact repository is a delivery surface, not the source of training policy.

5. Release HSSM last

Confirm HSSM accepts the released simulator floor and, when applicable, the promoted network metadata. Follow HSSM's own changelog, test, notebook, and publication procedure. HSSM uses v-prefixed release tags.

The documentation announcement is controlled by shared site configuration; there is no per-release banner edit. Documentation deployment runs from the documentation caller on main, independently of package publication.

6. Update feedstocks after PyPI verification

For each released PyPI package, update its conda-forge feedstock version, source hash, build number, and dependency floors through the feedstock's normal pull-request workflow. A feedstock change follows the package release; it does not substitute for verifying the PyPI artifact.

7. Verify downstream surfaces

  • Install each public package from its intended index in a clean environment.
  • Confirm package metadata and repository tags agree. Remember that LANfactory tags are bare while HSSM and ssm-simulators tags use v.
  • Verify promoted network metadata from the consumer path when artifacts changed.
  • Re-run the relevant drift and version-pin audits.
  • Record deferred downstream work in the owning repository.

If a release artifact is wrong, stop the train. Package indexes generally do not permit replacing an existing version: fix forward with a new version and document any yanked release through the package's normal release channel.

See dependency flow for why this order is load-bearing and source ownership for the boundary between Spine, packages, the pipeline, and artifact stores.