chore(release): 0.2.0

[anilcancakir]

Cuts 0.2.0, carrying the delete-affordance repair merged in #21 and the QA round merged in #22.

Minor rather than patch: three breaking changes, listed in CHANGELOG.md. Two are API shape and the third is behaviour that moves on upgrade with no code edit at all, which is the one worth reading twice.

• NotificationsListView.onDelete becomes Future<bool>. A host passing a Future<void> callback no longer compiles. The widget had no way to learn whether the row left, and the list is a separately paginated fetch, so it reloaded after every tap: a host that asks for confirmation spent a GET /notifications every time somebody declined one.
• deleteNotification rethrows a failed request instead of completing normally, so a caller can finally tell a delete that worked from one that did not.
• notifications.database.polling_interval now takes effect. It was validated by the CLI, reported by notifications:doctor and shipped in every install stub while the runtime read nobody, so every install effectively polled every 30 seconds whatever the config said. Both directions move: an app configured at 5 issues six times the requests it did yesterday, and one configured at 3600 is clamped to 600, so its bell can be ten minutes stale where it used to be thirty seconds.

Three host keys are newly required: notifications.channel_sms and notifications.delete from #22, and notifications.delete_failed from #21. Each renders as the raw key without it, and all three are called out in the changelog, which is what the release notes copy.

Six version sites, swept by shape rather than by the old number, which is the lesson 0.1.0 already recorded: pubspec.yaml, CHANGELOG.md, CLAUDE.md, README.md, doc/getting-started/installation.md, and the magicNotificationsVersion constant behind the command banners. Last release the doc was already ahead and needed no change, so a grep for the current version finds the wrong set in both directions. The constant is a site the release command's own table does not list and every previous release has bumped; install_command_test.dart:835 pins it to the pubspec, so the suite verifies that one rather than my having asserted it. The ^0.0.1 in test/cli/commands/uninstall_getter_test.dart is deliberately untouched: it is fixture data for a temp app's pubspec, not a version site.

Downstream, in order, and one of these is urgent. magic_starter's default branch can no longer compile against this package's default branch, because its _confirmThenDelete still returns Future<void>. Measured before merging #22, by pointing that repo's override at the branch:

error - src/routes/notification_routes.dart:85:39 - The argument type
'Future<void> Function(String)' can't be assigned to the parameter type
'Future<bool> Function(String)?'

uptizm inherits it, since it resolves both packages by path and compiles magic_starter from source. Neither is showing red yet, and that is not reassurance: CI in those repos runs on their own pushes, not on a sibling's change, so both are stale-green and the break surfaces on their next run. fluttersdk/magic_starter#122 is the fix and is drafted with its pin already at ^0.2.0, so the order is: merge this, publish 0.2.0, confirm it is live on pub.dev, then mark #122 ready (its published CI job is the only gate that can catch an unresolvable pin) and merge.

602 tests, dart analyze clean, dart format clean. dart pub publish --dry-run reports zero warnings, and there is no pubspec_overrides.yaml in this worktree, so that dry-run is already the state the publish workflow sees rather than a friendlier one.

Author: Anılcan Çakır anilcan.cakir@gmail.com

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

A clean six-site version sweep with nothing stale left behind; every claim in the description that I could execute, I executed, and all of them hold.

Minor

CHANGELOG.md:5 — Dated 2026-09-03, a day after the [0.1.0] entry's 2026-09-02, which is today. .claude/commands/release.md Phase 3 step 5 asks for "today's date in YYYY-MM-DD format". Harmless if the tag really lands tomorrow; otherwise the published entry is post-dated. (maintainability)

PR description — The body says "Two host keys are newly required" and names notifications.channel_sms and notifications.delete, but the changelog's Fixed section names a third, notifications.delete_failed, also required and also rendering as the raw key without it. The changelog is the correct one and it is what Phase 7 copies into the release notes, so adopters reading the release get all three; only the PR body undercounts.

Notes

• ^0.1.0 resolves >=0.1.0 <0.2.0 under pub_semver's zero-major rule, so no host on the old pin is dragged across the three breaking changes without editing its constraint. The minor bump is the right call.
• The ^0.0.1 in test/cli/commands/uninstall_getter_test.dart:64 is fixture data for a temp app's pubspec, not a version site: correctly left alone.
• The ## [0.2.0] heading is inserted above ### Breaking Changes, so all previously-unreleased content now sits under the release and [Unreleased] is empty. Correct.

Tests

test/cli/install_command_test.dart:829-835 reads pubspec.yaml at runtime and asserts magicNotificationsVersion equals it, so the constant bump is verified by the suite rather than by eye. No other version site is test-covered; I checked the remaining four by grep instead.

Checks I ran

• flutter pub get → Got dependencies (no pubspec_overrides.yaml present, confirming the description's claim).
• flutter analyze --no-fatal-infos → No issues found! (ran in 15.6s).
• dart format --output=none --set-exit-if-changed . → Formatted 97 files (0 changed).
• flutter test → 01:15 +602: All tests passed!.
• dart pub publish --dry-run → Package has 0 warnings. (255 KB archive).
• grep -rn '0\.1\.0' over the tree → only the [0.1.0] changelog heading, the >=0.0.6 <0.1.0 explanatory comment in pubspec.yaml:25, and an example string in .claude/commands/release.md:18. No stale version site.
• grep -rn 'magic_notifications: *\^' → README.md:66 and doc/getting-started/installation.md:30 both at ^0.2.0.

I did not verify the downstream magic_starter / uptizm breakage described in the body; that is outside this repository and I did not check it out.

[anilcancakir]

Both checked. One holds, one does not.

The third host key is real and my description undercounted it. notifications.delete_failed came in with #21 and is required exactly like the other two. The changelog has it, and since Phase 7 copies the changelog into the release notes, adopters were always going to get all three; only the summary a human reads was short. Description corrected.

The date is right, and the disagreement is a timezone. Right now it is 2026-09-02 21:34 UTC and 2026-09-03 00:34 +03, so which day this is depends on the clock you ask. Precedent settles it: the [0.1.0] entry is dated 2026-09-02 and its release commit landed at 2026-09-02 00:14:03 +0300, which was 2026-09-01 21:14 UTC. So this file has always been dated by local time, and by local time today is the 3rd. Leaving it.

Worth recording for whoever reads this next: the two clocks are three hours apart here, and just after local midnight they name different days. Print both in the same command before concluding a date is wrong.