release-versioning

Synchronizes workspace versions from Cargo.toml to binding manifests and integration packages.

9.2k|581|Updated Jan 31, 2025
One-click install
npx skills add https://github.com/kreuzberg-dev/kreuzberg --skill release-versioning
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release-versioning
Source: https://github.com/kreuzberg-dev/kreuzberg/tree/main/.ai-rulez/skills/release-versioning
Command: npx skills add https://github.com/kreuzberg-dev/kreuzberg --skill release-versioning

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Keeping dozens of package manifests (Python, npm, Maven, Helm, Go, Ruby) in sync with the core Rust workspace version is error-prone when done by hand, and drift between an integration's version and its xberg dependency pin breaks releases.

Core Features & Use Cases

  • Single source of truth: The root Cargo.toml [workspace.package] version (including -rc.N suffixes) drives every other manifest; nothing is hand-edited.
  • Three-step sync pipeline: task version:sync runs alef sync-versions for binding manifests, scripts/sync_integration_versions.py for integrations and the Helm chart, then ai-rulez generate --plugin to regenerate plugin bundles.
  • Lockstep integration publishing: Python (PyPI), Java (Maven Central), npm, and Helm chart packages are versioned and published together with core, with correct PEP 440 vs native semver formatting and exact or floor dependency pins.
  • Use Case: Before cutting release 1.0.0-rc.33, run task version:bump:patch so every integration manifest, the Helm chart, and plugin config update atomically, then verify with task version:check in CI.

Quick Start

Ask the assistant to bump the workspace version and sync all binding and integration manifests using the release-versioning workflow.

Frequently Asked Questions about release-versioning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I bump the version across all packages in a Rust monorepo?

Run `task version:bump:major|minor|patch` or `task version:set -- <version>`. These helpers update the root Cargo.toml and automatically chain the full sync to binding manifests and integrations, which you then commit together atomically.

How to keep Python and npm package versions in sync with a Cargo workspace?

Use `task version:sync`, which runs `alef sync-versions` for alef-managed binding manifests and `scripts/sync_integration_versions.py` for integrations under integrations/, the Helm chart, and plugin config. Never hand-edit individual manifest versions.

Does the version sync handle pre-release versions like 1.0.0-rc.32?

Yes. The Cargo version including `-rc.N` suffixes is authoritative. The sync script converts to PEP 440 form (`1.0.0rc32`) for pyproject files and keeps native semver form for Maven poms and npm package.json files.

Why should pyproject use a floor pin like xberg>=1.0.0rc32 instead of >=1.0.0?

Per PEP 440, a bare `xberg>=1.0.0` excludes all `1.0.0rcN` pre-releases, so the integration would fail to resolve against the rc core it ships with. Naming the rc in the floor pin is deliberate.

How do I add a new integration package to the version sync?

Add its manifest to `VERSION_TARGETS` in `scripts/sync_integration_versions.py`, and to `XBERG_DEP_MANIFESTS` if it depends on xberg. Do not add integration manifests to `alef.toml` `[workspace.sync]`, since alef would clobber their derived layout.

How do I detect version drift between integrations and core in CI?

Run `task version:check`, which prints the Cargo version and executes `sync_integration_versions.py --check`, failing the build if any integration manifest has drifted from core. Note it does not dry-run `alef sync-versions`.