Any PR that changes a package's version (which should be most PRs) should be published to pub.dev.
_See also: Package migration to 1.0.0
The packages in flutter/packages are automatically released with a Github Action workflow named “release”. If a commit on master branch contains version updates to one or more packages, the “release” CI will publish the new versions to pub.dev and push the release tag to GitHub. The “release” CI passes if
If you are a Flutter team member at Google and you need access to the publisher account, please see b/191674407.
The “release” CI only runs on post-submit, and waits until all the other CI jobs have passed before starting. Like any other CI job, The “release” CI blocks future PRs if failed.
Note: the “release” CI does not automatically publish the flutter_plugin_tools
package.
When a new package is released for the first time, it will be owned by the publisher account rather than the flutter.dev verified publisher. Someone with access (see above) needs to log into pub.dev with the publisher account and transfer the package to the verified publisher using the package's Admin tab.
If it is a flake (for example, network issue), a Flutter team member can simply run the CI again. For more complicated cases, a Flutter team member can also manually release the packages, then re-run the CI to pass.
The most common source of failure of the release
task is that another test failed; if that is due to flake, you will need to first re-run the failing test task, then once it's green re-run release
.
If something has gone wrong that prevents auto-publishing—most commonly, an out-of-band breakage that caused post-submit tests to fail for reasons unrelated to the PR that should have been published—a Flutter team member can publish manually. (An alternative to publishing manually is to revert and re-land the relevant PR; this is especially worth considering for PRs that affect many plugins.)
Some things to keep in mind before publishing the release:
To release a package:
git checkout <commit_hash_to_publish>
. This should be the commit of the PR you are publishing unless there's a very, very good reason you are using a different version.git status
is clean, and that there are no extra files in your local repository (e.g., via git clean -xfd
).publish
command from flutter_plugin_tools
. This command checks that you've done the step above, publishes the new version to pub.dev, and tags the commit in the format of <package_name>-v<package_version>
then pushes it to the upstream repository.If for some reason you can't use flutter_plugin_tools
in step 3, you can publish manually:
dart pub publish
.git tag
in the format of <package_name>-v<package_version>
git push upstream <tagname>
.Sometimes, despite our best efforts, breakage is found only after a package is published. Unlike flutter/engine or flutter/flutter a breaking PR that has been published cannot be directly reverted, since that would revert to an earlier, also-already-published version, which cannot be published. To fix published breakage: