Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Flutter version ranges #299

Open
bartekpacia opened this issue Apr 9, 2024 · 0 comments
Open

Add support for Flutter version ranges #299

bartekpacia opened this issue Apr 9, 2024 · 0 comments

Comments

@bartekpacia
Copy link
Collaborator

bartekpacia commented Apr 9, 2024

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:

environment:
  sdk: ">=3.0.0 <4.0.0"
  flutter: ">=3.10.0"

In my GitHub Actions, I have this:

jobs:
  main:
    name: Flutter ${{ matrix.flutter-version }}
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        flutter-version: ["3.10.x", "3.13.x", "3.16.x", "3.19.x"]

    steps:
      - name: Clone repository
        uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable
          flutter-version: ${{ matrix.flutter-version }}

Problems with it:

  • 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:

  • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant