Skip to content

Plugins CI should run for each framework change #33440

@amirh

Description

@amirh

Breaking changes in the framework sometimes break plugins code.
As the flutter/plugins plugins are running against master on CI, but are required to also work on latest stable it often makes it challenging to "fix" the issue in the plugins repository. 2 recent examples:

  1. Add template type parameter to invokeMethod calls in the plugins repo #26431
  2. Revive the "set marker icon" sample for Google Maps #33438

I suggest that we block landing framework PRs that are breaking the plugins repository. While seemingly this might leave the author with a chicken-and-egg problem(how can they update the plugin code to adapt to the breaking change before the framework change has landed), but not blocking landing the change just moves the issue downstream(we can't update the plugin code before the breaking change made it to stable).

So we should solve this chicken-and-egg issue early on when there's still the option to re-plan the landing process(e.g land the change in 2 phases, the second phase lands only after the first phase made it to stable).

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work listc: contributor-productivityTeam-specific productivity, code health, technical debt.packageflutter/packages repository. See also p: labels.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions