# Release

> Prepare and verify a slime release, including version bumps, stable Docker patch snapshots, Docker/conda dependency alignment, and release-specific validation. Use when cutting or auditing a slime release.

- Skill: `thudm/release` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add thudm/release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thudm/release/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: THUDM (https://skillmd.com/u/thudm)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/thudm/release

---


# Release slime

Prepare a release without publishing, tagging, pushing images, or changing the
dependency baseline unless the user explicitly requests those external or
scope-expanding actions.

## Establish the release baseline

- Inspect the worktree and preserve unrelated user changes.
- Compare the previous release tag and release commit to identify the current
  repository conventions.
- Confirm the requested slime version and the current stable SGLang version
  from `docker/Dockerfile` and `docker/README.md`.
- Do not pull in an unmerged SGLang/Docker upgrade merely because a newer
  branch exists. Treat that as a separate decision.

## Update release versions

- Set the package version in `setup.py`.
- Set the documentation version in `docs/conf.py`.
- Bump `docker/version.txt` to a unique image version following its existing
  dated naming convention.
- Search the repository for the old slime version and review every remaining
  occurrence instead of replacing unrelated dependency versions.

## Freeze the stable Docker patches

- Treat `docker/patch/latest/` as the patch stack for the current Docker base.
- Snapshot it exactly into `docker/patch/<stable-sglang-version>/`. At release
  time, the two directories must contain the same patch filenames and bytes.
- Preserve older SGLang patch directories. Remove an obsolete file from the
  current stable snapshot only after confirming it is absent from `latest`.
- Verify the stable patch stack applies in Dockerfile order to clean checkouts
  of the pinned SGLang and Megatron commits. Do not validate against a dirty
  developer checkout.

## Audit Docker and conda together

Compare `build_conda.sh` with `docker/Dockerfile`, `docker/justfile`, and the
stable patch snapshot. Check at least:

- SGLang version, commit, CUDA variant, `sglang-kernel`, and `sgl-deep-gemm`;
- Megatron, torch-memory-saver, FlashQLA, and other shared source pins;
- `PATCH_VERSION`, patch filenames, application order, optional patches, and
  failure-on-conflict behavior;
- PyTorch, torchvision, torchaudio, CUDA Python, Transformer Engine, router,
  NumPy, and SciPy pins;
- whether dependency resolution can undo a compatibility pin later in the
  script; reassert and validate such pins after the resolving install;
- intentional differences such as conda being CUDA-12-only, omitting FA3, or
  not rebuilding feature-specific DeepGEMM/DeepEP forks. Keep a difference
  only when the release CI scope makes it intentional.

Prefer direct loops over duplicated patch-application blocks while preserving
required-versus-optional semantics and useful failure messages.

## Validate before handoff

Run the checks that are available locally:

- `python .claude/skills/release/scripts/check_release.py --repo .
  --expected-version <version>`;
- `python setup.py --version`;
- `bash -n build_conda.sh`;
- byte-for-byte comparison of `docker/patch/latest/` and the stable snapshot;
- patch parsing plus clean-checkout application against the pinned upstream
  commits;
- `git diff --check` and a final review of the complete release diff.

Run the release conda CI and relevant Docker builds when the environment and
requested scope permit. The conda workflow is selected by a PR title containing
`[release]`. Explicitly report any full build or GPU validation that was not run.