update-project-version

von nvidia

Aktualisiere die NeMo-Fabric-Release-Version über Cargo, setuptools-Paketmetadaten, interne Python-Abhängigkeits-Pins, Integrationsmetadaten und Lockfiles. Verwende…

npx skills add https://github.com/nvidia/nemo-fabric --skill update-project-version

Update Project Version

Companion Guidance

Use karpathy-guidelines alongside this skill for implementation or review work. Keep changes scoped, surface assumptions, and define focused validation before editing.

Use this skill when changing the NeMo Fabric version, including pre-release or build-metadata variants used during packaging.

Source Of Truth

  • Cargo.toml [workspace.package].version is the source of truth for the Rust workspace and the release version stamped into Python and TypeScript package metadata.
  • Keep Cargo.toml [workspace.dependencies] self-references aligned when the workspace version changes.
  • sdk/python/nemo-fabric-runtime/pyproject.toml is the exception among the Python projects: do not add a literal project.version. Keep project.dynamic = ["version"] because Maturin derives nemo-fabric-runtime's version from crates/fabric-python/Cargo.toml, which inherits the workspace version.
  • The setuptools projects do not derive their versions from Cargo. Update the literal project.version in every one of these files:
    • sdk/python/nemo-fabric/pyproject.toml
    • adapter-contract/python/pyproject.toml
    • adapters/**/pyproject.toml
  • Keep internal Python package requirement pins aligned with the Python release version:
    • The unconditional nemo-fabric-runtime == <version> dependency in the published sdk/python/nemo-fabric/pyproject.toml.
    • All nemo-fabric-* == <version> requirements in its optional dependencies.
    • Each adapter's nemo-fabric-adapters-common == <version> dependency.
  • Keep adapter-contract/typescript/package.json and the root package entries in its package-lock.json aligned with the Cargo SemVer release version.

For a normal release, use the same X.Y.Z string everywhere. For a prerelease or build-metadata version, use valid Cargo SemVer in Cargo.toml and the equivalent PEP 440 version in explicit Python metadata. Confirm that the Maturin-built runtime and setuptools-built packages resolve to equivalent versions rather than blindly copying incompatible syntax.

Workflow

  1. Read the current version from Cargo.toml and decide the exact Cargo, Python, and TypeScript target version strings.
  2. Run just set-version <cargo-version>. The recipe preserves the normalized SemVer for Cargo and TypeScript, converts it to PEP 440 for Python, and updates:
    • Cargo.toml [workspace.package].version
    • Cargo.toml workspace.dependencies.nemo-fabric-core.version
    • The setuptools project.version in the published SDK metapackage, Python adapter contract, and every adapter pyproject.toml
    • Every internal nemo-fabric-* exact-version requirement
    • The TypeScript adapter-contract package.json and package-lock.json
    • Cargo.lock through Cargo metadata resolution
    • The root, runtime, and adapter uv.lock files through just lock-python
  3. Confirm that sdk/python/nemo-fabric-runtime/pyproject.toml remains dynamic and unchanged.
  4. Audit references to the old version with targeted searches. Distinguish package-version surfaces from examples and unrelated dependency versions.

If editing the helper code, keep these contracts aligned:

  • set_project_version must call the Cargo, Python, and TypeScript project version helpers.
  • set_cargo_workspace_version must update the workspace version and the nemo-fabric-core workspace dependency, then verify every nemo-fabric-* workspace package through Cargo metadata.
  • set_python_project_versions must update the published SDK metapackage, Python adapter contract, every adapter pyproject.toml discovered recursively under adapters/, and all internal exact-version pins while rejecting a static version in sdk/python/nemo-fabric-runtime/pyproject.toml.
  • set_typescript_project_version must update the package manifest and both root version entries in the npm lockfile without changing dependency versions.
  • The set-version recipe must run just lock-python after source metadata is updated.

Validation

  • Inspect Cargo version fields: rg -n '^version =|nemo-fabric-core = \{ path = .*version =' Cargo.toml
  • Inspect explicit Python versions and internal pins: rg -n '^version =|nemo-fabric-[a-z-]+(?:\[[^]]+\])? == ' pyproject.toml sdk adapter-contract/python adapters --glob 'pyproject.toml'
  • Confirm the runtime remains dynamic: rg -n 'dynamic = \["version"\]' sdk/python/nemo-fabric-runtime/pyproject.toml
  • Inspect the TypeScript package and lockfile root versions: rg -n '"version":' adapter-contract/typescript/package{,-lock}.json
  • Run cargo check --workspace --locked.
  • Run just build-python to verify all Python package metadata resolves.
  • Run just test-python when the integration version or Python packaging behavior changes materially.
  • Run just wheels for release-facing validation of every Python wheel.
  • Run just pack-typescript to verify the stamped TypeScript package metadata.
  • Run git diff --check.

Avoid

  • Updating only Cargo.toml and leaving the setuptools packages stale.
  • Adding a literal version to sdk/python/nemo-fabric-runtime/pyproject.toml; Maturin owns that version.
  • Updating Python package versions without their exact internal dependency pins.
  • Forgetting Cargo.lock, the root uv.lock, or per-project uv.lock files.
  • Updating the TypeScript package manifest without its npm lockfile root entry.
  • Blind repository-wide replacement of version-like strings.

References

  • Cargo.toml
  • Cargo.lock
  • pyproject.toml
  • uv.lock
  • sdk/python/nemo-fabric/pyproject.toml
  • sdk/python/nemo-fabric/uv.lock
  • sdk/python/nemo-fabric-runtime/pyproject.toml
  • sdk/python/nemo-fabric-runtime/uv.lock
  • adapter-contract/python/pyproject.toml
  • adapter-contract/python/uv.lock
  • adapters/**/pyproject.toml
  • adapters/**/uv.lock
  • adapter-contract/typescript/package.json
  • adapter-contract/typescript/package-lock.json
  • justfile

Mehr Skills von nvidia

compileiq-debug
nvidia
Verwenden, wenn etwas nicht stimmt: Search() hängt, alle Evaluierungen geben INVALID_SCORE zurück, Scores verbessern sich nicht, jede Konfiguration liefert dieselbe Zahl, ptxas-Fehler…
create-github-pr
nvidia
Erstelle GitHub-Pull-Requests mit der gh CLI. Verwende, wenn der Benutzer einen neuen PR erstellen, Code zur Überprüfung einreichen oder einen Pull-Request öffnen möchte. Auslöser-Schlüsselwörter -…
nemoclaw-maintainer-cross-issue-sweep
nvidia
Scannt andere offene Issues, um solche zu finden, die ein bestimmter PR möglicherweise ebenfalls behebt oder versehentlich kaputt macht. Gibt benachbarte Fix-Möglichkeiten und Widerspruchsrisiken mit Datei:Zeile… aus.
fhir-basics
nvidia
Bringt Agenten bei, wie FHIR R4 APIs funktionieren, welche Ressourcen verfügbar sind, wie man sie mit Suchparametern abfragt und wie man alle Antwortformate korrekt parst…
compileiq-validate-result
nvidia
Verwende NACH Abschluss einer Suche und VOR dem Einfordern eines Speedups oder dem Versand eines ACF. Lädt die dump_results CSV, extrahiert Top-K-Kandidaten (Einzelziel)...
changelog-audit
nvidia
Auditiere die CHANGELOG.md vor einem Release: stelle verlorene Einträge wieder her, sortiere nach Benutzerauswirkung, verfeinere die Sprache der Einträge, führe Zeilenumbrüche durch und (im Release-Branch-Modus) erhöhe die Vergleichsnummer…
maintain-dynamic-plugins
nvidia
Verwalte NeMo Relay dynamische Plugin-Lader, Manifeste, Rust native SDKs, gRPC Worker-Protokoll, Python Worker-SDK, Dokumentation, Tests und Abdeckung des Release-Workflows
dgx-diagnose
nvidia
Diagnostizieren Sie häufige DGX Station GB300-Probleme – CUDA-Abstürze, falsche GPU-Zuweisung, vLLM/SGLang-Container-Fehler, MIG-Status-Probleme, NVLink/Fabric-Manager-Fehler,…