Skip to main content

Release Process

This page describes what should be maintained when releasing the documentation site and runtime components.

Release Artifacts​

A formal release should confirm:

  • testudo-chart Helm Chart version.
  • testudo-operator image tag.
  • testudo-server image tag.
  • testudo-web image tag.
  • CRD schema changes.
  • OpenAPI spec changes.
  • Documentation site version and release notes.

Pre-release Checks​

pnpm build

Runtime repositories should also run their own tests and lint commands according to their Makefiles and CI.

Documentation checks:

  • README first-screen links are correct.
  • Installation, upgrade, rollback, and uninstall paths are correct.
  • The helm-repo release for testudo-chart contains the latest index.yaml, testudo-chart-<version>.tgz, and values*.yaml.
  • Compatibility matrix is updated.
  • API docs and OpenAPI spec are synchronized.
  • English and Chinese pages both exist.
  • Key screenshots still match the current console.

Release Notes​

Release notes should include:

  • New features.
  • Fixes.
  • Compatibility changes.
  • Breaking changes.
  • Upgrade steps.
  • Rollback notes.
  • Known issues.

Documentation Version​

After stable releases begin, freeze the release documentation with Docusaurus versioning. Keep current as the next development version.

GitHub And Gitee​

GitHub is the source of truth. Releases, issues, pull requests, security reports, and governance should happen on GitHub. Gitee repositories, when provided, should be treated as mirrors.