Workflow:Wandb Weave SDK Release
| Knowledge Sources | |
|---|---|
| Domains | Release_Engineering, CI_CD, Package_Management |
| Last Updated | 2026-02-14 11:00 GMT |
Overview
End-to-end process for releasing a new version of the Weave Python SDK, from version bumping through building and publishing to PyPI.
Description
This workflow covers the release process for the Weave SDK. It uses a two-phase version management system: first dropping the pre-release tag from the development version (e.g., 0.52.29-dev0 to 0.52.29) to create a release, then bumping to the next development version (e.g., 0.52.30-dev0). The process involves automated version bumping via the bump-my-version tool, git commit and tag creation, building the distribution package, and uploading to PyPI using Twine. An optional dry-run step validates that the pre-release version resolves correctly on Test PyPI before the production release.
Usage
Execute this workflow when preparing a new release of the Weave Python SDK. The trigger is typically a decision to ship accumulated changes on the master branch to users. The workflow should be run by a maintainer with PyPI publishing credentials and push access to the repository.
Execution Steps
Step 1: Validate Pre-release
Run the pre-release dry-run script to verify that the latest pre-release version installs correctly from Test PyPI. This catches packaging issues before committing to a production release.
Key considerations:
- The script checks that the current development version (with -dev0 suffix) resolves and installs correctly
- Failures at this stage indicate build or metadata issues that must be resolved first
- This step is optional but recommended for catching issues early
Step 2: Bump Version for Release
Run the version bumping script to remove the pre-release tag. This transforms the version from X.Y.Z-dev0 to X.Y.Z, creates a git commit with the release version, and tags the commit with the version number.
Key considerations:
- The script uses bump-my-version to modify weave/version.py and related configuration
- A git commit is created automatically with the version change
- A git tag is created for the release version
- The -dry-run flag allows previewing the version change without modifying files
Step 3: Bump Version for Next Development Cycle
Run the version bumping script again to advance to the next development version. This increments the patch number and adds the -dev0 suffix (e.g., X.Y.Z to X.Y.(Z+1)-dev0), creating another git commit.
Key considerations:
- This step immediately follows the release bump to begin the next development cycle
- The pre-release suffix prevents accidental installation of unreleased code from source
- Both commits (release and next-dev) should be pushed together
Step 4: Push Commits and Tags
Push the version bump commits and the release tag to the remote repository. This makes the release version and tag visible to CI systems and other maintainers.
Key considerations:
- Push both commits and tags in a single operation
- The release tag triggers downstream processes (changelog generation, notifications)
- Verify the commits are clean and contain only version changes before pushing
Step 5: Build the Distribution Package
Build the source distribution and wheel using the Python build tool. The publish script handles cleaning the dist directory, building the package, and preparing it for upload.
Key considerations:
- The build uses the tagged release version from weave/version.py
- Both sdist and wheel formats are generated
- The dist directory is cleaned before building to prevent uploading stale artifacts
Step 6: Publish to PyPI
Upload the built distribution to PyPI using Twine. Authentication is handled via environment variables. An optional test upload to Test PyPI can be performed first to validate the package before production release.
Key considerations:
- Authentication requires TWINE_API_KEY or TWINE_USERNAME/TWINE_PASSWORD environment variables
- The --test flag uploads to Test PyPI for validation
- The --dry-run flag builds without uploading for local verification
- Once published, PyPI versions are immutable and cannot be overwritten