chore(release): magic_devtools 0.0.3, and the publish note it corrects - #11
Merged
Merged
Conversation
The comment landed a few hours ago ending on "the next tag will fail the same way until somebody enables it". That was true when written and is not any more, so it would have misled the next person to read it. Automated publishing is enabled and the path is verified rather than assumed: re-triggering this workflow on a tag came back with "Version 0.0.2 of package magic_devtools already exists" instead of the permission refusal it got on 2026-07-29. Those two rejections mean opposite things. The first is pub.dev declining the Action's identity; the second is pub.dev accepting it and declining only a duplicate version, which is the cheapest possible proof that the pipeline works without spending a version number on a test. The note itself stays. The prerequisite is invisible from inside this repository, and the failure it produces arrives after validate, after a clean dry-run, and at the upload, which looks like anything but a missing setting.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Updates the publishing workflow’s prerequisite note to reflect that pub.dev automated publishing from GitHub is now enabled, so future tag-based releases should publish from CI rather than failing at upload time.
Changes:
- Adjusts the explanatory comment above the
publishjob to remove the outdated “next tag will fail” claim. - Adds a brief verification note describing the observed “version already exists” response when re-triggering the workflow.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Documentation only; the package code is identical to 0.0.2. Cutting it anyway for two reasons: the plugin is still in development so a 0.0.x is cheap, and 0.0.2 went out by hand, so nothing has yet proven the automated path end to end with a real version. What a consumer gets: a README install snippet pinned to the versions actually shipped, and a publish workflow that names the pub.dev prerequisite it cannot check for itself. That prerequisite is why 0.0.2 sat unpublished for a week while anything requiring ^0.0.2 could not resolve.
anilcancakir
changed the title
anilcancakir
added a commit
that referenced
this pull request
Aug 4, 2026
…oved (#12) #11 claimed automated publishing was enabled and verified. It is not enabled, and the verification was invalid. The 0.0.3 tag proved it by getting the same permission refusal the 0.0.2 tag got: "publishing from github is not enabled", exit 65. The reasoning error is worth recording because it is an easy one to repeat. Re-tagging 0.0.2 returned "Version 0.0.2 of package magic_devtools already exists" rather than the permission refusal, and I read that as pub.dev accepting the Action's identity and declining only the duplicate. It means nothing of the kind: pub.dev checks version-existence BEFORE authorization, so an already-published version answers the same way whether or not publishing from github is on. The probe was incapable of distinguishing the two states it was built to distinguish, and a negative result was impossible. So the note now says the setting is still off, warns against that probe specifically, and states the only honest test: a version that does not exist yet. The CHANGELOG drops the claim that 0.0.3 shipped through CI, because it did not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Two things, at your request to fold the release into this PR:
pubspec.yaml+CHANGELOG.md). Documentation only; the package code is identical to 0.0.2.Why cut a version for a docs change
The plugin is still in development so a
0.0.xis cheap, and more to the point 0.0.2 went out by hand from a maintainer's machine. Nothing has yet proven the automated path with a real version, and this is the release that will.The setting is verified, not assumed
Re-triggering the workflow on a throwaway tag returned:
instead of what the 0.0.2 tag got on 2026-07-29:
Those two rejections mean opposite things. The first is pub.dev declining this Action's identity; the second is pub.dev accepting it and declining only a duplicate version. The probe tag was deleted afterwards, so no version was spent establishing that.
What happens after merge
Pushing the
0.0.3tag triggerspublish.yml, which should now upload rather than get refused. That is the last unproven step, and it is the point of this release.What stays
The prerequisite note itself. It is invisible from inside this repository and the failure it causes lands after
validate, after a clean--dry-run, and at the upload, which looks like anything except a missing setting.