Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.charmos.io/llms.txt

Use this file to discover all available pages before exploring further.

This page will become the docs entry point for Charm release notes. Use the changelog to understand what changed between releases, whether you need to upgrade, and which operational steps are required.

​
Planned Sections

  • Latest release.
  • Recent changes.
  • Breaking changes.
  • Migration notes.
  • Older releases.

​
Release Categories

Charm release notes should group changes into:
  • Features.
  • Fixes.
  • Breaking changes.
  • Infrastructure and migrations.
  • Documentation.
  • Internal maintenance.

​
What to Look For

Before upgrading, check:
  • required SDK or CLI version,
  • charm.yaml compatibility changes,
  • migration or deploy requirements,
  • runtime image changes,
  • billing/auth/security notes,
  • known issues.

​
Release Notes

Charm uses Release Drafter to prepare draft GitHub Releases from merged pull requests. Release owners should review the generated draft, fill in the summary and upgrade notes, then publish it from GitHub Releases.

​
Source of Truth

GitHub Releases are the source of truth for published changelogs. The docs changelog should link to published releases and only duplicate release text when a docs-native archive is needed.

​
Pull Request Labels

Every user-facing pull request should include one release label:
  • release:feature for new capabilities.
  • release:fix for bug fixes.
  • release:breaking for incompatible API, CLI, runtime, or manifest changes.
  • release:security for security fixes or hardening.
  • release:infra for deployment, runner, billing, auth, or migration changes.
  • release:docs for documentation-only changes.
  • release:chore for internal maintenance that should still appear in release notes.
  • release:skip for changes that should not appear in release notes.
Use release:major, release:minor, or release:patch only when the default version bump from the category label is not correct. The release label check requires exactly one category label on every pull request. The label sync workflow creates and updates these labels in GitHub when the workflow runs.