There are a few issues here:

1. flutter_cocoon in customer tests pins the previous version of Mockito.. This can be worked around by temporarily excluding the test (disable flutter_cocoon test to unblock flutter/flutter#140169 tests#329) and putting it back after
2. All of the plugin packages also pin the same version of Mockito so they need to be published with new constraints (bump is at bump mockito across repo to 5.4.4 packages#5794 then they just need publishing)

I think with those issues fixes, this PR may go green. Then we should also be able to bump DDS, vm_service, vm_service_interface and DWDS (or, the bot might be able to do it for us).

2. All of the plugin packages also pin the same version of Mockito so they need to be published with new constraints

Is there some context in which the published packages are being used in a development context? They only have dev dependencies on mockito, so there is no plan to publish that change.

@stuartmorgan it's the bots on this PR that are failing. For example "Linux flutter_plugins":

https://github.com/flutter/flutter/pull/140916/checks?check_run_id=20140583080
-> https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20flutter_plugins/62066/overview
-> https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8759887933573737393/+/u/run_test.dart_for_flutter_plugins_shard_and_subshard_analyze/test_stdout

Running command: "flutter pub downgrade" in /b/s/w/ir/x/t/flutter_packages.NZDZNB/packages/camera/camera
Resolving dependencies...
Note: test_api is pinned to version 0.7.0 by flutter_test from the flutter SDK.
See https://dart.dev/go/sdk-version-pinning for details.

Because mockito >=5.4.1 <5.4.4 depends on test_api >=0.2.1 <0.7.0 and every version of flutter_test from sdk depends on test_api 0.7.0, mockito >=5.4.1 <5.4.4 is incompatible with flutter_test from sdk.
So, because camera depends on both flutter_test from sdk and mockito 5.4.3, version solving failed.

I originally assumed these were being cloned from the packages repo directly, but if they are landing the above PR to update the packages might cause these bots to fail (until this PR also lands). If they're instead coming from pub, then the versions on Pub would need to be updated for this PR to go green?

Actually, I can see at the top of the log clone https://github.com/flutter/packages.git so I guess it is pulling from the repo. Let me re-run the bots now flutter/packages#5794 has landed..

Linux flutter_plugins is using a pinned version of flutter/packages, not pub. You'll need #140967 in your PR's branch.

For example "Linux flutter_plugins"

Are there other examples? That test is unique, so if other things are failing, they would probably be doing so in a completely different way and need to be addressed individually.

Are there other examples? That test is unique, so if other things are failing

There are some failing customer tests, but that's because cocoon is also pinned (noted above). I think those were the only ones, but I'll review the latest results.

You'll need #140967 in your PR's branch.

Ah, thanks, I'll merge in! :)

Actually, I think I confused myself. I thought pkg:test was pinning Mockito (so I expected the PR you linked above to fail because Flutter is pinned to an older test that couldn't use new Mockito).

However, it seems like the dependency is the other way (mockito pins test), so I think #140967 can be landed in isolation (and is not required in this PR, beyond using it to test that those bots now pass).

So I think the problem is a little simpler now. Once #140967 lands, if the only failure here is customer_tests because of cocoon, we can land flutter/tests#329 and then land this.

(and then hopefully update dds/dwds/etc.! 😄)

@christopherfujino seems we're down to just customer tests failing now. Your cocoon failure will fix one, but I also see some like this:

| 00:05 +17 ~1: /Volumes/Work/s/w/ir/x/t/flutter_customer_testing.flutter_svg.spGB4E/tests/packages/flutter_svg/test/widget_svg_test.dart: SvgPicture.string
| Warning - golden differed less than .06% (0.010147916666666666%), ignoring failure but producing output
| Golden "golden_widget/flutter_logo.string.png": Pixel test failed, 1.01% diff detected.
| Failure feedback can be found at /Volumes/Work/s/w/ir/x/t/flutter_customer_testing.flutter_svg.spGB4E/tests/packages/flutter_svg/test/failures
|
| 00:05 +18 ~1: /Volumes/Work/s/w/ir/x/t/flutter_customer_testing.flutter_svg.spGB4E/tests/packages/flutter_svg/test/widget_svg_test.dart: SvgPicture.string

It's not clear to me if this is a real failure or not. One line says it's ignored because it's less than 0.06% but the next line says it's 1.01 🙃

@christopherfujino @bkonyi if I re-run flutter update-packages --force-upgrade on this PR now, it pulls in vm_service 14. Do we want to pin vm_service 13 for now? (I don't know if it's this unpin that is allowing it to be upgraded now, but if it's not, the bot might try to upgrade it).

@christopherfujino @bkonyi if I re-run flutter update-packages --force-upgrade on this PR now, it pulls in vm_service 14. Do we want to pin vm_service 13 for now? (I don't know if it's this unpin that is allowing it to be upgraded now, but if it's not, the bot might try to upgrade it).

I think we need to pin to 13.0.0 until this CL lands in the SDK and we're also ready to land this change in DevTools to handle the breaking changes. If we land 14.0.0 in Flutter as-is without the SDK change, we'll break the DevTools build. Even if we patch DevTools, network profiling will be broken without the SDK changes.

FYI @derekxu16

ok, I'll open a separate PR that pins that to ensure it's not accidentally rolled in (with or without this PR).

Edit: #140972

I don't think package:vm_service needs to be pinned to 13.0.0 in Flutter. DevTools has its own constraint that will prevent pacakge:vm_service 14.0.0 from being used until we're ready.

https://github.com/flutter/devtools/blob/6315c98ee58565469ebde2697b4a0bae1042704c/packages/devtools_app/pubspec.yaml#L61

I don't think package:vm_service needs to be pinned to 13.0.0 in Flutter. DevTools has its own constraint that will prevent pacakge:vm_service 14.0.0 from being used until we're ready.

https://github.com/flutter/devtools/blob/6315c98ee58565469ebde2697b4a0bae1042704c/packages/devtools_app/pubspec.yaml#L61

We should probably pin it regardless since the relevant changes in the SDK haven't landed and 14.0.0 won't work with any Flutter version that doesn't have it.

We should probably pin it regardless since the relevant changes in the SDK haven't landed and 14.0.0 won't work with any Flutter version that doesn't have it.

Upon looking into this further, we actually must not pin package:vm_service to 13.0.0 in Flutter. The reason why https://dart-review.googlesource.com/c/sdk/+/341120 hasn't landed is because it currently fails cbuild smoke testing. To make it pass cbuild smoke testing, package:devtools_app needs to first be updated in response to the breaking changes in package:vm_service 14.0.0, and then rolled internally. package:devtools_app depends on package:integration_test from the Flutter SDK, which depends on package:vm_service, so the Flutter SDK must be updated to accept package:vm_service 14.0.0 before flutter/devtools#6953 can land. See the current check results on flutter/devtools#6953: https://github.com/flutter/devtools/actions/runs/7450073310.

We should probably pin it regardless since the relevant changes in the SDK haven't landed and 14.0.0 won't work with any Flutter version that doesn't have it.

Upon looking into this further, we actually must not pin package:vm_service to 13.0.0 in Flutter. The reason why https://dart-review.googlesource.com/c/sdk/+/341120 hasn't landed is because it currently fails cbuild smoke testing. To make it pass cbuild smoke testing, package:devtools_app needs to first be updated in response to the breaking changes in package:vm_service 14.0.0, and then rolled internally. package:devtools_app depends on package:integration_test from the Flutter SDK, which depends on package:vm_service, so the Flutter SDK must be updated to accept package:vm_service 14.0.0 before flutter/devtools#6953 can land. See the current check results on flutter/devtools#6953: https://github.com/flutter/devtools/actions/runs/7450073310.

Ah okay that makes sense. As long as 14.0.0 doesn't make it into the in-progress Flutter release, we should be fine.

So should I revert #140972 which pinned it?

So should I revert #140972 which pinned it?

It will need to be reverted at some point, but we should probably wait until the branch cut is complete just to be safe.

Ok, let me know when that is if you want me to do it (or feel free to create the revert).

I'm gonna close this PR (that unpins test packages) for now - the original intention was to try and get an updated DDS into Flutter for the branch but I think that's being resolved via a hotfixed version instead. We can look at unpinning these also after the branch and it's not a limiting factor for DDS now as I understand it.