xinjian0101-continuity-director/docs/RELEASING.md

Release Process

This document defines the release workflow for Continuity Director.

Version source

VERSION is the canonical public version and release trigger. The same value must appear in __init__.py, pyproject.toml, README.md, CHANGELOG.md, and docs/releases/v<version>.md. The unit suite rejects inconsistent public version references.

Release readiness

A release candidate must satisfy:

• CI passes on Python 3.10, 3.11, and 3.12.
• ComfyUI lifecycle import succeeds.
• Unit and frontend smoke tests pass.
• Release validation and installable ZIP validation pass.
• Maintainer-health checks pass.
• Public node identifiers and schema compatibility are reviewed.
• User-visible changes are documented in CHANGELOG.md.
• Supported-version, upgrade, and limitation notes are current.

Automated patch release

1. Resolve or explicitly defer release-blocking Issues.
2. Update VERSION and all validated public references in a pull request.
3. Add docs/releases/v<version>.md.
4. Run the full validation sequence from README.md.
5. Merge only after the Python 3.10–3.12 CI matrix passes.
6. The Publish release workflow runs automatically on main.
7. The workflow validates the repository, builds the installable ZIP, creates a SHA-256 checksum, creates the v<version> tag, and publishes a GitHub prerelease.
8. Verify the release page and perform a clean installation from the published ZIP.
9. Record real compatibility results in the linked roadmap Issue.

Manual recovery

The release workflow can also be started from the Actions page. If publication fails after validation, correct the workflow or repository state through a pull request and rerun it. Do not silently replace an already published release.

Version policy

• Patch releases fix defects, improve compatibility, or strengthen documentation and reliability without intentional breaking changes.
• Minor releases may add nodes or schema capabilities while preserving migration paths.
• Breaking changes require explicit migration documentation and a major-version decision.

Rollback

If a release artifact is defective, mark the release notes clearly, keep the prior known-good release available, open a public corrective Issue, and prepare a tested patch release.