4372bfbc6c
<!-- start_original_pr_link -->
Reverts: flutter/flutter#169451
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: matanlurey
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: Broke a number of post-submit tests
(ios_app_extension, packages_autoroller).
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: mosuem
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {matanlurey}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
Reland after #169357.
Switch Flutter to use pub workspaces as a preparation to unpin selected
packages.
Assumptions:
1. No packages in this repository are published to pub.dev --> We can
use `any` dependencies in most local pubspecs, as the global constraint
defines the version. An exception are the packages used outside of this
repo with an `sdk` dependency, namely `flutter_localizations`,
`flutter_test`, and `flutter`.
2. The "universes" `{flutter_tools}` and `{flutter,
flutter_localizations, flutter_goldens}` can use different packages
versions, as they are not resolved together. --> We do not need to
upgrade them in sync, we can first do one "universe", then the other.
Based on these assumptions, we use
https://github.com/mosuem/pubspec_merger.dart to merge all packages in
the `flutter` universe into a top-level pub workspace.
The `flutter` and `flutter_tools` workspaces being separate also ensures
that changes to `flutter` will not inadvertently break `flutter_tools`,
with not-so-nice consequences for our users which would be unable to run
`flutter upgrade`.
There is a third "top-level" pubspec besides `./pubspec.yaml` and
`packages/flutter_tools/pubspec.yaml`, namely
`packages/flutter_tools/.../widget_preview_scaffold/pubspec.yaml`. This
is an artifact due to it living under `flutter_tools`, so it can't be
part of the `./pubspec.yaml` workspace. Moving it would be a larger
change, and out of the scope of this PR.
This required a rewrite of the update-packages tool, but the main
functionality stays the same, as well as the argument names, to ensure a
seamless transition.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
|
||
|---|---|---|
| .. | ||
| bin | ||
| core | ||
| README.md | ||
| RELEASE_ONBOARDING.md | ||
Flutter Conductor
Command-line tool for managing a release of the Flutter SDK. Also see Release Process for more information on the release process.
Conductor Requirements
Some basic requirements to run conductor are:
- a Linux or macOS computer set up for Flutter development. The conductor does not support Windows.
- git
- Mirrors on GitHub of the Flutter ** framework and engine repositories.
For the best experience, it is recommended to use ssh protocol for connecting to
GitHub remote repositories (i.e. for --framework-mirror and --engine-mirror
specify the remote with the format git@github.com:username/reponame). If your
local ssh key is password-protected, it is recommended to use ssh-agent to
unlock your ssh key for the session; if you do not, each time the conductor
attempts to interact with a remote, the user will be prompted to enter their ssh
key password.
** Confirm that your personal GitHub clone of flutter/flutter is named flutter and flutter/engine is named engine. If not you will need to use flags to override the defaults.
Usage
The main entrypoint for the conductor is bin/conductor. For brevity, the rest of this document will assume that this entrypoint is on the shell path.
All available commands can be seen via:
conductor help
Releases are initialized with the start sub-command, like:
conductor start \
--candidate-branch=flutter-2.2-candidate.10 \
--release-channel=beta \
--github-username=kingOfDevelopers \
--dart-revision=4511eb2a779a612d9d6b2012123575013e0aef12 \
The conductor will, based on the release channel and the presence/lack of
previous tags, determine which part of the release version should be
incremented. In the cases where this is not correct, the version can be
overridden with --version-override=3.0.0.
For more details on these command line arguments, see conductor help start.
This command will write to disk a state file that will persist until the release
is completed. If you already have a persistent state file, this command will
fail with an error message. To see the current status of the release (at any
time), issue the command:
conductor status
To delete a persistent state file (either because the release was successfully completed or abandoned), use the command:
conductor clean
Once initializing the release, the conductor tool will issue instructions for
manual steps that must be executed by the user. At any time these instructions
can be seen via conductor status. Once these manual steps have been completed,
you can proceed to the next step by using the command:
conductor next
Steps
Once the user has finished manual steps for each step, they proceed to the next step with the command:
conductor next
Publish Version
This step will add a version git tag to the final Framework commit and push it to the upstream repository. The presence of a tag affects what the flutter CLI tool reports the current version is.
Publish Channel
This step will push the Framework candidate branch to the upstream release
branch (e.g. the stable branch). Once this push happens upstream, the release
has officially been published, and the code will be available to existing
Flutter users via flutter upgrade.
Verify Release
For the final step, the user must manually verify that packaging builds have finished successfully. The SDK compressed archives will not be available from the website until the packaging build has finished. The conductor will produce links to the dashboards for monitoring CI builds.
Post verificaion steps (mostly communication)
Googler instructions for post release documented at go/flutter-release-workflow#notify