dependencies change for flutter depending on channel/minor update? (material_color_utilities added in dev but not stable)

[aliak00]

Scenario: dev1 is on flutter dev channel which is 2.9.0-0.1.pre and runs flutter pub get and gets this:

@@ -163,6 +163,13 @@ packages:
       url: "https://pub.dartlang.org"
     source: hosted
     version: "0.12.11"
+  material_color_utilities:
+    dependency: transitive
+    description:
+      name: material_color_utilities
+      url: "https://pub.dartlang.org"
+    source: hosted
+    version: "0.1.2"
   meta:
     dependency: transitive
     description:
@@ -307,7 +314,7 @@ packages:
       name: test_api
       url: "https://pub.dartlang.org"
     source: hosted
-    version: "0.4.3"
+    version: "0.4.8"
   typed_data:
     dependency: transitive
     description:

So they commit and push.

And then dev2 is running flutter stable so is on version 2.8.1 currently and runs flutter pub get and gets a new diff (because there's no material_color_utilities package dependency in flutter then.

So I guess one option would be to pin the flutter version in the pubspec.yaml but I feel that this would not be good practice? Is that the recommended approach?

Or, is there some configuration file within a project that can enforce which channel your global flutter installation is on? Though that won't work because as 2.9.0 is moved to stable then the same would happen I assume. So then is pinning the flutter version to only minor version updates recommended?

And there's also another question of: should this not be considered as a "breaking change" and hence a major version update? You can technically look at this as changing the output of a public api of the flutter cli. Though I don't know if that counts, but still curious on thoughts here.

Thanks!

[darshankawar]

@aliak00
This PR was merged recently #94377 and will be able on latest master but may not have been available on stable yet and hence the diff you are seeing.
Also, since dev channel is going to be de-commissioned soon as part of stable 2.8.0 announcement, please try the same using master and see if it helps to answer your question.

[aliak00]

@darshankawar Yeah i understand the reason for the diff. Wondering how to deal with this situation though and if there's a recommended approach from the flutter team.

Also, since dev channel is going to be de-commissioned soon as part of stable 2.8.0 announcement

Do you mean maybe 2.9.0 maybe? (as 2.8.0 is announced here: https://docs.flutter.dev/development/tools/sdk/release-notes/release-notes-2.8.0, or, is that considered as the stable announcement?)

please try the same using master and see if it helps to answer your question.

You'll have the same scenario if dev1 is on stable and dev2 is on master. As flutter has brought in a new dependency.

You'll also get the same scenario when flutter 2.9.0 is pushed to stable. Then people who are on flutter 2.8.0 and people who are on flutter 2.9.0 will get diff clashes. So that's why I'm wondering if the flutter team recommends to pin the flutter version to only upgrade the patch version. And also the more wider question around is this really a minor change when you bring in a dependency that change the output of a public API?

[darshankawar]

@aliak00
Thanks for the details. Usually the changes are merged into master first, then in beta and finally in stable once everything is tested functionally, so the material_color_utilities you are seeing on master only but will eventually land in stable in next release. See this document for more details on release cycles. https://github.com/flutter/flutter/wiki/Flutter-build-release-channels

[aliak00]

Hey @darshankawar thanks for the speedy responses! Yes, I also understand the release cycle already :)

My question is more around flutter version pinning and recommended approaches to avoid diff clashes like this and if this is valid minor semver upgrade practice.

When material_color_utilities lands on stable 2.9.0, developers who are on flutter 2.8.0 will create diff clashes with developers who have updated to 2.9.0. In teams with more than 1 person this is problematic unless there's some version pinning or maybe some ci mode?. Since a new flutter app by default specifies sdk: '>=2.15.0 <3.0.0' I assume that's the the flutter team saying "this should work without issues", but this causes problems if flutter adds dependencies across minor versions which causes lock file ping-ponging between developers. I believe for e.g. npm will never create a lock file clash between minor version upgrades of itself. Same with other package managers (probably??).

So flutter seems to be doing something inconvenient here, and possibly creating a breaking change to its public CLI API across minor version upgrades.

[darshankawar]

@aliak00
Thanks for the update. To properly address your query, I think it's better to ask / raise this on Flutter's discord platform and not here, since this platform is generally for tracking bugs and feature requests.
Closing from here.

[aliak00]

I think this is a bug/issue in flutter though. I asked on the discord channel as well - not helpful.

I think my issue has not been understood here. Maybe @goderbauer, @zanderso, or @darrenaustin can check. Is the commit in question ok given its impact?

[zanderso]

I believe the way this particular change was landed correctly followed our processes, and that the version numbers make sense. However, the open question is what are best-practices for ensuring that all members of a team are using a consistent version of Flutter.

I suspect that pinning the Flutter SDK version in the pubspec.yaml will work, but I'll add @Hixie and @mit-mit here as well for possibly better advice.

[mit-mit]

Flutter made a design choice to pin package versions, and thus any individual Flutter SDK is compatible only with that set of single pinned versions of all packages, as opposed to a semantic range of versions. This has the benefit that we can test and assure the quality of the SDK and it's set of dependent package versions, but then also the disadvantage that it is limited to that single version. As a consequence I would recommend developers working jointly on an app to all use the exact same Flutter SDK version. Note that this recommendation is specific to apps; package authors should always try to develop packages that support semantic ranges.

Wrt. tooling that can help enforce this, unfortunately Flutter SDK constraint in the pubspec (https://dart.dev/tools/pub/pubspec#sdk-constraints) only supports a lower-constraint and not an upper-constraint, so there is no way of using that to restrict resolution to a single Flutter release. The only workaround I can think of is to narrow the Dart SDK constraint, as the Dart SDK inside Flutter gets updated with every Flutter release.

[aliak00]

@mit-mit Ok! Thanks for the input! So just to confirm, flutter SDK x.y.z is not meant to be compatible with x.y.w but if it is then cool - and maybe also more likely is than not (?). Fair enough then!

Does it make sense to have a mechanism in flutter to enforce the same SDK version in the project given flutter's design choice to pin packages? And, additionally, to have something like flutter use-version x.y.z so devs can ping pong between projects? (because I think flutter downgrade only goes down one version, and flutter upgrade goes to the latest only?)

[zanderso]

The flutter CLI doesn't natively do anything more sophisticated than the downgrade and upgrade commands. Folks in the Flutter community have built the tool fvm (https://fvm.app/), which sounds like could be useful to you, though.

[Hixie]

flutter upgrade et al just use git behind the scenes, so you can just do that. Some people use a git submodule in their package pointing to a specific version of flutter, for example.

[stuartmorgan]

I'm going to close this, as there doesn't seem to be anything actionable for Flutter here; the observation that if different people use different versions of Flutter to build the same application they will get different package resolution is true, but is also unavoidable in general, since even if Flutter doesn't change things, packages used by the app may have different compatibility.

(#95472 already tracks the question that was raised in discussion about controlling Flutter version.)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.