Repository navigation
[flutter_tools] pubspec.yaml environment.flutter constraint not respected by pub get #95472
Description
Activity
@neiljaywarner
Is there any reason why you need to change it to>=2.8.0 <2.8.1" or "2.8.0"?
On latest stable 2.8.1, the dart version supported is 2.15.1 (fromflutter doctor) .Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.@darshankawar sorry I didn't see your question.
I want to pin it so if I go away for 6 to 18 months and come back I know what flutter version this project expects and will compile on.
Yes I know updating is important but so is keeping everyone on a project on the same tested version- Specifically I would like it to behave as expected consistently in both directions and enforce upper constraint as well as lower constraint. Not just force/remind devs to upgrade when the team decides to but disallow them to race ahead. For example ci should not be able to make a build with a flutter version never tested by qa ....sent from my phone…On Mon, Jan 10, 2022, 8:58 AM github-actions[bot] ***@***.***> wrote: Reopened #95472 <#95472>. — Reply to this email directly, view it on GitHub <#95472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBGYPMMDPT4S5GKON7BRLUVLXY5ANCNFSM5KJIXPCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>Reacted by Erik Tetland
The current version with upper constraint I have is
sdk: ">=2.8.1 <3.0.0"which works well, indicating the min lower and max upper version constraint, so I am not entirely sure what your request here is.- What you have should disallow 3.0 0 it fails the constraint of bring less than or equal to 3.0 In fact 3.0 would pass and be compile and build except for the fact that 3.0 is a major version and would have breaking changes. Honestly I want to be able to constrain to 2.8.1 for example so 2.8.0 fails and 2.8.2 fails. I don't ever want the project upgraded silently by random dev or random server with no pr review or discussion. This concept weeks with the lower constraint but upper constraint is broken and as far as I could tell does nothing. Thanks ....sent from my phone…On Tue, Jan 11, 2022, 12:00 AM darshankawar ***@***.***> wrote: The current version with upper constraint I have is sdk: ">=2.8.1 <3.0.0" which works well, indicating the min lower and max upper version constraint, so I am not entirely sure what your request here is. — Reply to this email directly, view it on GitHub <#95472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBGYND6UZTHEZFVZSECILUVPBPTANCNFSM5KJIXPCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>
Keeping it open and labeling for further input.
41 remaining items
It is true that Flutter does not use semantic versioning for breaking releases. But presumably we could still support upper bounds on environment.flutter. :)
...Or perhaps a flag in pubspec.yaml saying you want to enforce strict version checking for the flutter sdk. This would be backwards compatible with existing pubspecs. Along the lines of:
environment: sdk: '>=3.5.0 <4.0.0' flutter: 3.29.2 strict_flutter_version_checking: true
Reacted by Neil Jay WarnerIt looks like this behavior was originally added in dart-lang/pub@d74520a Which appears to have been a request from Tim Sneath. 🤣 #68143
My guess is what's happening here is the divergence of desires between packages and applications. I expect that Tim's original request was so that not every flutter-using package in the Dart ecosystem would need an update just because Flutter announced Flutter 2, since by default ^1.0.0 will disallow usage of the package with Flutter 2 and thus the day that Flutter 2 was announced, you couldn't use it because all of your packages (which probably would work fine) suddenly would refuse to work with your version of Flutter because it was now not aligned with the ^1.0.0 constraint.
However this also meant that then Apps were no longer able to restrict the version of Flutter used, because (at least the way it was implemented) apps no longer had a way to specify they wanted exactly 1.0.0.
This is in part due to how Flutter uses (abuses?) semver, by having X.Y.Z and Z is incremented on each hotfix. Y is incremented every month (e.g. beta release) and X was intentionally controlled by product management and arbitrarily incremented every time we wanted to make a splash about flutter haven't changed enough that we should have an event, etc.
Anyway, I think I'm stuck at this point. I can't get a working test environment for pub locally (7 tests fail for me) and I have other demands on my time. So I may look at this again (or someone else should feel free to attempt to 1. get pub tests working locally and 2. finish the posted patch). My guess is that the proper solution here is going to be to one of:
- splitting behavior of "apps" vs. "packages" (not sure how that would work?)
- adding a new key to pubspec.yaml to be a real flutter constraint
- adding some new key to opt in to this behavior
- give up on this behavior and just make it so that when Flutter 4 is announced, all pub packages depending on flutter won't work with Flutter 4, because their constraints will be >=3 <4 🤷
If anyone would like to pick up where I left off dart-lang/pub#4578 has a PR (including a text file containing the 7 failures I'm seeing locally with a clean Dart 3.7.3 sdk archive for Arm64 mac from https://dart.dev/get-dart/archive
Reacted by Alex LiTo restate (for clarity) the problem that I understand this bug to be about.
There is no official way to record "this app should be built with version x.y.z of Flutter".
As currently implemented, if one use the environment.flutter constraint, one would, at minimum, need to look at the pubspec.yaml rather than pubspec.lock because the spec might say 1.2.3 but the lock will say >=1.2.3.
This arrises because of the workaround added in dart-lang/pub@d74520a. That workaround was targeted a libraries to avoid a library which was OK with Fluter 1.x suddenly needing to re-publish when Flutter 2.x was released, even though 2.x had no breaking changes for that library. When the flutter/dart ecosystem was smaller, that was a very bad thing for Flutter 2 release day. :)
There are lots of 3p attempts at adding ways to express "this app should be built with flutter x.y.z". fvm, puro, etc. have per-package "lock" files for a flutter version. There is just no "flutter official" place to put this information.
How we (shorebird) got involved here was simply that we were attempting to teach
shorebirdto determine the version of Flutter to use for building a project (as part of fixing shorebirdtech/shorebird#2529). When we realized the environment.flutter method was unreliable, we had 3 options: we (shorebird) make yet another way, fix this one, or bless one of these 3p ways as being the "standard".It's not a huge blocker for us. Just attempting to re-summarize this long issue and explain why my attention got drawn to this (briefly) this week.
Reacted by Neil Jay Warner and Greg PriceOh two other quick comments
- I'm working with a very large Enterprise right now and concerns about upgrading flutter have come up
- It's a really big problem in my opinion that since you can't pin the flutter version if you set aside something and come back to at 6 or 12 months later, you don't even know what flutter version it was built with
Reacted by maxdreherwalsworthSome unthoughtful idea: How about introducing "!x.y.z" for specific version constraint pin?
After discussing this offline we ended up agreeing that we will change pub to respect the upper bound flutter constraint for any root pubspec (that is, the pubspecs of the workspace).
That is a breaking change, but most likely not very disruptive, as usually you can change the pubspecs of the workspace, while it is harder to.
Reacted by Dan SyrstadSounds good. I think the only time it will be "disruptive" is when Google launches Flutter 4.0 and it takes months for ones favorite packages to work with 4.0. (As I recall that was the original motivation for this current behavior was launching Flutter 2.0.)
Right, but that is a lot less disruptive for a root pubspec (for those the developer likely owns the source code and can quickly update it), than it is for the many packages that are listed as dependencies in that root pubspec. These packages often come from pub, and would need a coordinated effort across the ecosystem to get the contraints updated.
Reacted by Eric SeidelFixed by dart-lang/pub#4595
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 -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Jul 1, 2025
steps to reproduce
Expected behaviour - flutter pub get error
Actual behaviour: pub get succeeds; vesrion constraint fails, overzealous dev or build server just ugpraded to a newer version of flutter without discussion or any testing at all or possibly even an easy OOTB way to see what version was built with