feat: allow fixed flutter version constraints. #4578
Conversation
Previously there was code to treat x.y.z as >=x.y.z, specifically for the flutter sdk version constratint. This change removes that which allows app authors to specify an upper bound on the flutter version constraint for their projects.
|
very exciting @eseidel thank you so much |
|
Yeah, even following all instructions (installing a fresh dart-only sdk, etc) I still get 7 failures locally (even without this change) making it very difficult to work on pub. |
|
Sorry about the failures. We have CI running on mac where all tests are passing, but I usually develop on linux. I have just run all tests successfully on my mac. It seems from the stack traces that there is some problem with running freshly compiled subprocesses. Do you have any protection in place that only allows you to run recognized binaries? |
|
About the PR itself. The special casing is there for a reason - we don't want packages to claim compatibility with some flutter , and then flutter publishes a new major version (for marketing purposes) and then you cannot use the old packages. I personally was not too fond of this hack it back when it was put in place, but as long as Flutter insists to use its major version for marketing, and not for semantic versioning we need something like this hack in place for the ecosystem to continue working. We could consider changing again slightly how we interpret flutter sdk constraints. Perhaps
Or another plausible solution would be
Each of these have the potential to be breaking changes. And we would need to run a feasibility analysis across all current packages on pub.dev to see how many packages are affected. |
|
How about we fix it in two stages?
1)Low-hanging fruit: Make it so that an app ( not a package ) can "pin" a
single version with no range
2) the other more carefully measured steps
Many of those of us from a 'regular Android' (java/kotlin) school of
thought have it deep in our DNA to never use ranges but always pin a single
version.
(sorry it's not a good time for me to find a good link for it, perhaps it's
even old but it was strongly recommended in the past, correct? ie
recycler-view-1.1.1 rather than whatever their equivalent of the caret was.
…On Thu, May 15, 2025 at 3:07 AM Sigurd Meldgaard ***@***.***> wrote:
*sigurdm* left a comment (dart-lang/pub#4578)
<#4578 (comment)>
About the PR itself. The special casing is there for a reason - we don't
want packages to claim compatibility with some flutter , and then flutter
publishes a new major version (for marketing purposes) and then you cannot
use the old packages.
I personally was not too fond of this hack it back when it was put in
place, but as long as Flutter insists to use its major version for
marketing, and not for semantic versioning we need something like this hack
in place for the ecosystem to continue working.
We *could* consider changing again slightly how we interpret flutter sdk
constraints. Perhaps
- We in general ignore the upper bound of the constraint
- But if the constraint is a single version we respect both the upper
and lower bound (ie. we constrain to just that version).
Or another plausible solution would be
- We in general respect upper and lower bound of the constraint
- Unless it is a '^x.y.z' constraint, in which case we just consider
the lower bound.
Each of these have the potential to be breaking changes. And we would need
to run a feasibility analysis across all current packages on pub.dev to
see how many packages are affected.
cc @mit-mit <https://github.com/mit-mit> @jonasfj
<https://github.com/jonasfj>
—
Reply to this email directly, view it on GitHub
<#4578 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ2W5FX6LSFXG4KDEBPMDL26RDMFAVCNFSM6AAAAAB5EPUASKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBSHE2TAOJUGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
re: freshly compiled subprocesses. Not to my knowledge. This is a mostly-unaltered apple M3. |
|
Can you repeat here some of the reasons you want to pin the flutter sdk version? Perhaps we need a separate mechanism for that. |
|
I can try to give specific use case later but bottom line every single
feature every single Branch should always have the same flutter version for
1) developer's local flutter install
2) qa or Qe engineera build whether from source or through app distribution
such as firebase
3) the build servers that deploy
It should never be possible for a human to accidentally upgrade flutter on
their local machine and still be able to run the project
It should never be possible for a build server that was accident on a
configured to use stable channel instead of a pinned version to upgrading
and build on a newer version of flutter
It should absolutely not matter for this purpose whether it was a major or
minor or hot fix flutter change because many organizations want and need to
make sure it is absolutely the same .
…On Fri, May 16, 2025, 3:49 AM Sigurd Meldgaard ***@***.***> wrote:
*sigurdm* left a comment (dart-lang/pub#4578)
<#4578 (comment)>
Can you repeat here some of the reasons you want to pin the flutter sdk
version?
Perhaps we need a separate mechanism for that.
—
Reply to this email directly, view it on GitHub
<#4578 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ2W5CWNHJ36Q2RKOF4TQD26WRBJAVCNFSM6AAAAAB5EPUASKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBWGA3DONZTHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The problem we (Shorebird) were looking to solve is that @sigurdm there is currently no official way to record "this set of source should use version X.Y.Z of flutter". I'm not sure this constraint is the right way to record that. Also, as currently implemented, if one used this constraint, one would 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. My understanding is that the real problem here (ignoring this potential solution) is that this "hack" was added for libraries, but the problem that flutter/flutter#95472 is looking for a solution for is for apps (that want to record somehow the exact version of Flutter the developer should use). There are lots of 3p attempts at this. fvm, puro, etc. have per-package "lock" files for a flutter version. There is just no "flutter official" place to put this information, so either we (shorebird) make yet another way, fix this one, or bless one of these 3p ways as being the "standard". In any case, I should be clear, I don't feel super passionate about this. We were just trying to change our |
Previously there was code to treat x.y.z as >=x.y.z, specifically for the flutter sdk version constraint. This change removes that which allows app authors to specify an upper bound on the flutter version constraint for their projects.
This isn't actually ready for landing, because I haven't yet been able to successfully get a clean run of pub tests locally on my mac (maybe they aren't expected to run cleanly on a mac?) even without any changes to pub.
Fix for flutter/flutter#95472.