---
name: prepare-flet-release
description: Use when asked to prepare new Flet release by bumping versions and author release notes.
---

## 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/updates/release-notes.md` and
  `website/docs/updates/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.