Open jonasfj opened 1 month ago
Discussing this offline, it appears that while this could be a tiny improvement, it might not be worth the squeeze.
What we really want is probably more like:
name: mypkg
api:
dart: 3.5.0 # indicating that we want the language version and API shipped in 3.5
Of course that leads down the road of designing API versioning.
At the Flutter 2.0.0 release it was determined that Flutter did not follow semantic versioning, and for this reason the upper-bound SDK constraint on Flutter should be ignored.
Hence,
is currently re-interpreted as:
Avoiding this re-interpretation of the Flutter SDK constraint would make it more consistent with the Dart SDK constraint. And in the scenarios where these SDK constraints are useful, it would allow package authors / application developers to use them.
Do note that when Flutter 4 is released, we might then have to do a trick similar to what we did around Dart 3, where we say that Flutter 4 still supports packages that have an upper-bound of
<4.0.0
(but not packages that have<3.999.0
).To avoid compatibility issues we propose that we re-introduce the Flutter SDK constraint upper-bound by, either: