# Prepare Flet Release

> Use when asked to prepare new Flet release by bumping versions and author release notes.

- Skill: `flet-dev/prepare-flet-release` (Agent Skill)
- Install (CLI): `npx skillmds@latest add flet-dev/prepare-flet-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/flet-dev/prepare-flet-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: flet-dev (https://skillmd.com/u/flet-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/flet-dev/prepare-flet-release

---


## Inputs

* Previous Flet version from repo tags.
* Whether it's minor or major release.

## Related Skills

Always use [`flet-deprecation`](../flet-deprecation/SKILL.md) during release prep
to audit deprecations for the target version. Also use it when release prep includes:
- adding new deprecations in this release,
- removing APIs whose `delete_version` equals this release version,
- auditing changelog entries that mention deprecations/removals.

Use [`write-changelog-entry`](../write-changelog-entry/SKILL.md) for drafting or refining individual changelog items.
That skill is the source of truth for item wording, scope selection, and what should or should not be mentioned in a single entry.

## Steps

* Take latest Flet release version from the repo and
  increment third (patch) digit to get the next version if it's a minor release
  or second (minor) digit if it's a major release.
* Pull the latest `main` and create a new branch named `prepare-release-{new_version}` from `main`.
* Set new version in packages/flet/pubspec.yaml.
* Run pub get in /client dir to refresh pubspec.lock with new version.
* Add new entries into `packages/flet/CHANGELOG.md` and `/CHANGELOG.md` from the git log since the last release.
  * Use [`write-changelog-entry`](../write-changelog-entry/SKILL.md) for every individual item.
  * Build the candidate set from relevant commits, PRs, and issues since the last release.
  * Ensure that all inferred PRs and issues in the changelog have the `{version}` milestone attached on GitHub.
  * If a related issue or PR is missing the `{version}` milestone, update the milestone on GitHub and keep the link in the changelog.
  * When selecting candidates for `packages/flet/CHANGELOG.md`, prefer items with meaningful Flutter-side impact.
  * When selecting candidates for `sdk/python/packages/*/CHANGELOG.md`, prefer published Python-facing changes; do not include extension-internal Flutter implementation work unless it materially changes user-visible Python behavior.
* If the release includes breaking changes, API removals, or deprecations,
  update `website/docs/release/release-notes.md` and
  `website/docs/release/breaking-changes/index.md`.
  * Use [`flet-deprecation`](../flet-deprecation/SKILL.md) for deprecation
    guide requirements and sidebar placement.
  * Group related deprecations into one migration guide page where possible,
    and add guide pages under the release version in `website/sidebars.yml`.
* Scan all changelogs for `Unreleased` sections, not only the root ones:
  * `/CHANGELOG.md`
  * `packages/flet/CHANGELOG.md`
  * `sdk/python/packages/*/CHANGELOG.md`
  Recommended check command:
  `rg -n "^##\\s*\\[?Unreleased\\]?|^##\\s*Unreleased" -S CHANGELOG.md packages/flet/CHANGELOG.md sdk/python/packages/*/CHANGELOG.md`
* If any changelog has an `Unreleased` section, convert that section into the new release section (`## {new_version}`), preserving and re-sorting its items. Do not leave duplicate release content in both `Unreleased` and `{new_version}`.
  This conversion must be done for every matched changelog from the scan above.
* Sort items in changelogs as follows, omitting empty sections:
  * New features
  * Improvements
  * Breaking changes
  * Deprecations
  * Bug fixes
  * Documentation
  * Other changes (chore, refactor, etc.)
  Put removals of previously deprecated APIs under `Breaking changes`, and
  keep newly deprecated-but-still-working APIs under `Deprecations`.
* Templates are in `sdk/python/templates/` and automatically packaged as zip artifacts with the GitHub Release. No manual branch creation in external repos is needed.