Skip to content

RELEASING.md

Latest commit

 

History

History
51 lines (34 loc) · 1.85 KB

RELEASING.md

File metadata and controls

51 lines (34 loc) · 1.85 KB
Raw

Release Process

1. Bump Version

Edit Cargo.toml to bump the version (both the main version and the package versions)

Run

make lint-rs

This will update Cargo.lock, sync package.json/package-lock.json (via crates/monty-js/build.rs), and sync the pydantic-monty metapackage's version and its exact pins on pydantic-monty-client/pydantic-monty-runtime (via crates/monty-python/build.rs).

2. Commit and Push

git checkout -b prepare-release-vX.Y.Z
git commit -am "Bump version to vX.Y.Z"
git push

3. Create Release via GitHub UI

Once the PR is merged, create a release in the GitHub UI with a tag matching the version in Cargo.toml.

4. CI Handles Publishing

Once the tag is pushed, CI will:

  • Build wheels for all platforms
  • Publish to PyPI (pydantic-monty-client wheels, pydantic-monty-runtime wheels, and the pydantic-monty metapackage that pins both)
  • Publish to NPM (@pydantic/monty + the platform packages carrying the napi library, the monty binary, and the wasm build)
  • Publish the Rust crates to crates.io (monty, monty-types, monty-alloc, monty-fs, monty-runtime, monty-macros, monty-proto, monty-pool, monty-type-checking, monty-typeshed) via cargo publish --workspace

crates/monty-js/scripts/assemble-packages.mjs stages the main npm package under npm/main/ and adds exact platform optionalDependencies there before packing. The development manifest and lockfile omit these dependencies so version bumps do not need unpublished packages. CI tests the assembled tarballs, then publishes the platform packages before the main package.

Monitor the workflow at https://github.com/pydantic/monty/actions

Pre-release Tags

For pre-releases (alpha, beta, rc), use a tag like v0.0.2-beta.1:

  • PyPI: Published normally
  • NPM: Published with --tag next (not latest)