Whenever I bump the minimum Flutter version, I have to also remove it from CI workflow
Whenever a new Flutter version is released, I need to remember to add it to CI workflow
Idea
I suggest addition of flutter-version-range and flutter-version-range-file property:
- name: Set up Flutter
uses: subosito/flutter-action@v2
with:
channel: stable
flutter-version-range-file: pubspec.yaml # path to pubspec.yaml
Assuming the pubspec.yaml defined above, this would return [3.10.6, 3.13.9, 3.16.9, 3.19.5] (latest PATCH versions for every MINOR version).
Except it wouldn't work, because then we only know the versions at runtime, but to make a matrix build we need to known them statically.
It would also increase complexity of this action.
For now, I think the best action forward is to create a script (either Sh/Bash or Dart - the second would be likely much better because the pub_semver package could be used). Then this script could be wrapped into an new GitHub Action targeted mainly at package/plugin authors.
Then the CI workflow from above could be split into 2 jobs:
As a plugin maintainer, I want to run my CI to test/analyze/format my plugin against Flutter version it supports.
For example, let's say my plugin supports at least Flutter 3.10.0, so I'll have this in
pubspec.yaml
:In my GitHub Actions, I have this:
Problems with it:
Idea
I suggest addition of
flutter-version-range
andflutter-version-range-file
property:Assuming the
pubspec.yaml
defined above, this would return[3.10.6, 3.13.9, 3.16.9, 3.19.5]
(latest PATCH versions for every MINOR version).Except it wouldn't work, because then we only know the versions at runtime, but to make a matrix build we need to known them statically.
It would also increase complexity of this action.
For now, I think the best action forward is to create a script (either Sh/Bash or Dart - the second would be likely much better because the
pub_semver
package could be used). Then this script could be wrapped into an new GitHub Action targeted mainly at package/plugin authors.Then the CI workflow from above could be split into 2 jobs:
job get_flutter_versions
, outputs[3.10.6, 3.13.9, 3.16.9, 3.19.5]
job main
, gets the versions as input and uses them to create a matrix build