chore(release): 0.0.4 - #16
Conversation
MagicPerfIntegration, the performance data path assembled in the one package that can see dusk, telescope, wind and magic at once. Also raises the four sibling floors to what the code actually needs. They were magic ^0.0.6, dusk ^0.0.9, telescope ^0.0.4 and wind ^1.2.1, and every one sat below the release that introduced an API this package calls: onRefreshUI in magic 0.0.7, the perf_readers pointers in dusk 0.0.12, FramePerfWatcher in telescope 0.0.5, WindPerfCounters in wind 1.5.0. A caret resolves to the newest available, so a fresh resolution always picked the right siblings and CI stayed green. A consumer holding one back would have had pub call the graph satisfiable and the build then fail on undefined symbols, which is exactly what this branch's CI did while ^1.2.1 still resolved wind 1.4.1. Verified against the published graph with no local overrides: resolves magic 0.0.8, dusk 0.0.13, telescope 0.0.5, wind 1.5.0; analyze clean, format clean, 110 tests green.
|
Note Kodizm (AI-generated). May contain mistakes; verify before acting. Correct release bump, and the four raised floors verified as both real and sufficient; the one gap is that Major
Minor
Tests
Checks I ran
|
…ainst 0.0.3's changelog states the snippet pins the versions actually shipped, "so a copy-paste resolves to the combination this package is tested against". It had stopped doing that: magic_devtools ^0.0.2, dusk ^0.0.9, telescope ^0.0.4 against a release that ships 0.0.4, 0.0.13 and 0.0.5. Not a resolution failure, which is worth being precise about since the review that raised this read the constraints as `>=0.0.2 <0.0.3` and so on. A caret on a 0.0.x raises the MINOR for its upper bound, so `^0.0.2` is `>=0.0.2 <0.1.0` and admits 0.0.4; `^0.0.9` admits 0.0.13 and `^0.0.4` admits 0.0.5, none of them conflicting with the new floors. Checked with pub_semver rather than recalled. The snippet was stale against its own stated contract, which is reason enough. Changelog heading moved from 2026-08-26 to 2026-08-25, matching the five sibling releases tagged in this same batch and the UTC day the commits carry.
|
Both addressed in On the Major: the action is right, the mechanism is not. The README snippet was stale and I have refreshed it, but it would not have failed resolution. A caret on a So What is correct in the finding is the part that matters: 0.0.3's own changelog says the snippet "pins the versions actually shipped, so a copy-paste resolves to the combination this package is tested against", and it had stopped doing that. Now On the Minor: taken. Moved to On the red CI: infrastructure, not this branch. The run failed in |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Note Kodizm (AI-generated). May contain mistakes; verify before acting. Both earlier findings are addressed in Since Your correction on caret semantics stands and my Major overstated the mechanism: TestsUnchanged by this commit; the 110 passing tests I ran on Checks I ran
|
1 participant
What
magic_devtools0.0.3 to 0.0.4, shippingMagicPerfIntegration(#14), and raising the four sibling dependency floors to what the code actually needs.The floors were all too low
Every one of the four pins sat below the release that introduced an API
MagicPerfIntegrationcalls:magic^0.0.6^0.0.7MagicController.onRefreshUIfluttersdk_dusk^0.0.9^0.0.12perf_readers.dartpointersfluttersdk_telescope^0.0.4^0.0.5FramePerfWatcher,TelescopeStore.recentFramePerf/clearFramePerffluttersdk_wind^1.2.1^1.5.0WindPerfCounters,Wind.installPerfResolver()A caret range resolves to the newest version available, so a fresh resolution always picked up the right siblings and CI stayed green. A consumer whose own constraints hold one of them back would not: pub reports the graph as satisfiable and the build then fails on undefined symbols.
That is not hypothetical. It is what this branch's own CI did while
^1.2.1was still resolving wind 1.4.1: 18 errors, every one namingWindPerfCountersorinstallPerfResolver. The run only went green after wind 1.5.0 reached pub.dev, which is the accident these floors were relying on.What ships in it
MagicPerfIntegrationassembles the performance-diagnostic data path across four packages, which can only happen here: dusk's frozen dependency contract forbids it from importing any of the packages whose data it reports, so the pointer assignment has nowhere else to live.It sets
MagicController.onRefreshUIto a counter keyed by controller runtime type, registers aNavigatorObserverthat times each route push to the first post-frame callback after the new route builds, installs wind's perf resolver and telescope'sFramePerfWatcher, and assigns dusk's four reader and session-hook pointers.installPre()is where it goes, and it is no longer safe to call late:MagicRouter.addObserverthrows once the router has been built. That throw is deliberate, because a swallowed one would produce a report with no route transitions and nothing to explain their absence.Release gate, against the published graph
Verified with
pubspec_overrides.yamlmoved aside, so this is the graph an adopter gets:magic 0.0.8,fluttersdk_dusk 0.0.13,fluttersdk_telescope 0.0.5,fluttersdk_wind 1.5.0dart analyzeno issuesdart format --output=none --set-exit-if-changed lib testcleanflutter test110 passingdart pub publish --dry-run0 warningsPublish
Merge, then
git tag 0.0.4 && git push origin 0.0.4.This is the last unpublished work in the ecosystem. Every other package's pub.dev version already matches its default branch.