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.