Closes https://github.com/flutter/flutter/issues/173904.
It's not clear to me how `git describe --tags HEAD` ever ... worked to
determine a fallback. From what I can tell, the _intent_ was to use the
latest (newest? closest?) tag as the base version, and then append
`-{commitCount}-{shortHash}` as the fallback version number when on
`master` (or any non-published branch).
So, I rewrote the implementation, unfortunately with 4 separate calls
out to `git ...` instead of a single one.
There are 20+ tests that fail as a result of this change, mostly because
they make specific expectations around `git describe` being invoked, and
of course that is no longer the case - putting those aside, I'd like to
double check that:
1. I understand what the original command was _intending_ to do
2. We like the _output_ of the updated command
3. ... we either are okay with the implementation, or have an
alternative in mind (I'm no `git` master)
Wdyt?
At this commit:
```sh
$ flutter-dev --version
Flutter 3.36.0-1.0.pre-170 • channel [user-branch] • https://github.com/matanlurey/flutter
Framework • revision 250381a185 (5 minutes ago) • 2025-08-19 18:57:36 -0700
Engine • hash f278b0aa3b8c6732ab636563eb8e896c35fc9c79 (revision 9ac4facf7e) (2 hours ago) • 2025-08-19 23:42:28.000Z
Tools • Dart 3.10.0 (build 3.10.0-115.0.dev) • DevTools 2.49.0
```
/cc @zanderso @jmagman for historics.
Closes https://github.com/flutter/flutter/issues/74165.
The original issue called for, on Windows, telling `CYGWIN` to use
`=noglob`, to work around some git operation errors that happen when
using non-native Git. There ... was no great way to do this with the
existing codebase without, IMO, adding lots of confusing code.
So, I refactored all the calls of:
- before: `processUtils.<method>(['git', ...args], ...params)`
- after: `git.<method>([...args], ...params)`
... and implicitly add the new environment variables, if
`Platform.isWindows`.
Did some minor test cleanup and process execution cleanup while I was at
it.
The `frameworkVersion` string written to the version files wasn't
actually parsable by `GitTagVersion` as it didn't match the format
output by `git`.
This change updates the `frameworkVersion` format to use a `-` instead
of a `.` before the commit count and adds support to the version parsing
regex to handle both `.` and `-` separators before the commit count.
Fixes https://github.com/flutter/flutter/issues/172091
Sources under `packages/flutter_tools/` aren't accessible to the average
Flutter user by navigating through sources from their projects, so it
doesn't need to be as explicitly verbose with types for readability
purposes. The `always_specify_types` lint results in extremely verbose
code within the tool which adds little value.
This change disables `always_specify_types` in favor of a new set of
lints that aim to reduce verbosity by removing obvious types while also
maintaining readability in cases where variable types otherwise wouldn't
be obvious:
- `omit_obvious_local_variable_types`
- `omit_obvious_property_types`
- `specify_nonobvious_local_variable_types`
- `specify_nonobvious_property_types`
In the case of a bad release, we should be able to release a new version
of Flutter that points to the revision of the last good release.
This change updates the tool to not only compare framework revisions
when determining if the current installation is up to date, and also
updates the tag selection logic to pick the most recent version tag
first.
Fixes https://github.com/flutter/flutter/issues/170679
The flutter tool will now download and use an `engine_stamp.json` file
to determine the engine version, content hash, build date, and commit
date.
The file is treated as a new `DevelopmentArtifact.informative` and is
fetched before flutterVersion is used. This ensures we have build
information for a clean checkout with no bin/cache folder. Users that
download from flutter.dev will have engine_stamp.json, so its a no-op.
This change provides support for content hashed engine artifacts, who's
revision (the hash) is not a git commit sha. A side benefit is "git" is
only used at build time to extract this information.
> [!NOTE]
> Content hashed artifacts are not enabled yet for downloads;
bin/internal/engine.version (releases) and the shell updaters still look
for the git commit sha. One can test this out by setting
`FLUTTER_PREBUILD_ENGINE_VERSION` to the content hash.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
I am making an assumption `OutputMode.none` should _really_ mean
`OutputMode.failuresOnly`, that is, if we ever get a non-zero exit code,
we still want to know why. If I've somehow misunderstood that, LMK and
I'm happy to revert this PR or make adjustments.
This fixes the bug where if you were to do:
```sh
git clone https://github.com/myuser/fork-of-flutter
cd fork-of-flutter
./bin/flutter update-packages
```
You now get:
1. An actual error message, versus no output at all.
2. A warning that a common reason is not tracking a remote, with
instructions to fix it.
Closes https://github.com/flutter/flutter/issues/148569.
This pull request fixes#143803 by taking advantage of Dart's null-aware operators.
And unlike `switch` expressions ([9 PRs](https://github.com/flutter/flutter/pull/143634) and counting), the Flutter codebase is already fantastic when it comes to null-aware coding. After refactoring the entire repo, all the changes involving `?.` and `??` can fit into a single pull request.
Fixes https://github.com/flutter/flutter/issues/133093
When I introduced the new, more robust version file `//flutter/bin/cache/version.json` in https://github.com/flutter/flutter/pull/124558, I changed `class FlutterVersion` into an abstract interface, implemented by `_FlutterVersionFromGit` (which is essentially the previous behavior) and `_FlutterVersionFromFile`, which merely reads the data it would have computed via git from `//flutter/bin/cache/version.json`.
While doing this, I made `_FlutterVersionFromGit.ensureVersionFile()` to be a no-op, since I assumed this would not be necessary since we already had a version file in the cache. However, this method was what was previously responsible for ensuring `//flutter/version` existed on disk. This means that if, for whatever reason, the user had `//flutter/bin/cache/flutter.version.json` present but NOT `//flutter/version`, the tool would have never created that file, and they would hit the tool crash seen in https://github.com/flutter/flutter/issues/133093.
This fixes the tool by ensuring `//flutter/version` exists regardless of if we're hydrating `FlutterVersion` from `//flutter/bin/cache/flutter.version.json` or not.
Fixes https://github.com/flutter/flutter/issues/112833
Most of the actual changes here are in [packages/flutter_tools/lib/src/version.dart](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605), while the rest is largely just addressing changes to the constructor of `FlutterVersion` which now has different dependencies.
This change makes `FlutterVersion` an interface with two concrete implementations:
1. `_FlutterVersionGit` which is mostly the previous implementation, and
2. `_FlutterVersionFromFile` which will read a new `.version.json` file from the root of the repo
The [`FlutterVersion` constructor](https://github.com/flutter/flutter/pull/124558/files#diff-092e00109d9e1589fbc7c6de750e29a6ae512b2dd44e85d60028953561201605R70) is now a factory that first checks if `.version.json` exists, and if so returns an instance of `_FlutterVersionFromGit` else it returns the fallback `_FlutterVersionGit` which will end up writing `.version.json` so that we don't need to re-calculate the version on the next invocation.
`.version.json` will be deleted in the bash/batch entrypoints any time we need to rebuild he tool (this will usually be because the user did `flutter upgrade` or `flutter channel`, or manually changed the commit with git).
## How we determine the channel name
Historically, we used the current branch's upstream to figure out the current channel name. I have no idea why. I traced it back to https://github.com/flutter/flutter/pull/446/files where @abarth implement this and I reviewed that PR and left no comment on it at the time.
I think this is confusing. You can be on a branch and it tells you that your channel is different. That seems weird.
This PR changes the logic to uses the current branch as the channel name.
## How we display channels
The main reason this PR exists is to add channel descriptions to the `flutter channel` list:
```
ianh@burmese:~/dev/flutter/packages/flutter_tools$ flutter channel
Flutter channels:
master (tip of tree, for contributors)
main (tip of tree, follows master channel)
beta (updated monthly, recommended for experienced users)
stable (updated quarterly, for new users and for production app releases)
* foo_bar
Currently not on an official channel.
ianh@burmese:~/dev/flutter/packages/flutter_tools$
```
## Other changes
I made a few other changes while I was at it:
* If you're not on an official channel, we used to imply `--show-all`, but now we don't, we just show the official channels plus yours. This avoids flooding the screen in the case the user is on a weird channel and just wants to know what channel they're on.
* I made the tool more consistent about how it handles unofficial branches. Now it's always `[user branch]`.
* I slightly adjusted how unknown versions are rendered so it's clearer the version is unknown rather than just having the word "Unknown" floating in the output without context.
* Simplified some of the code.
* Made some of the tests more strict (checking all output rather than just some aspects of it).
* Changed the MockFlutterVersion to implement the FlutterVersion API more strictly.
* I made sure we escape the output to `.metadata` to avoid potential injection bugs (previously we just inlined the version and channel name verbatim with no escaping, which is super sketchy).
* Tweaked the help text for the `downgrade` command to be clearer.
* Removed some misleading text in some error messages.
* Made the `.metadata` generator consistent with the template file.
* Removed some obsolete code to do with the `dev` branch.
## Reviewer notes
I'm worried that there are implications to some of these changes that I am not aware of, so please don't assume I know what I'm doing when reviewing this code. :-)
* Create a main alias for master channel.
To slowly migrate away from master branch in the flutter repository we
created a main branch that is mirroring master branch. This PR is also
adding a channel alias that will allow to use master/main interchangeably.
Bug: https://github.com/flutter/flutter/issues/95041
* Fix channel tests.
* Remove additional space.
