-
Notifications
You must be signed in to change notification settings - Fork 30.1k
Closed
Labels
P2Important issues not at the top of the work listImportant issues not at the top of the work listc: contributor-productivityTeam-specific productivity, code health, technical debt.Team-specific productivity, code health, technical debt.packageflutter/packages repository. See also p: labels.flutter/packages repository. See also p: labels.
Description
We currently test flutter/plugins (and flutter/packages, but in practice this hasn't been a significant issue there so far) on master and latest stable. This means that sometimes we accidentally publish versions that don't work on older versions without realizing that we should have updated the constraints, and break everyone still using older versions of Flutter (recent examples include #98660 and #95706)
We have a few options:
- Always bump all minimum constraints when each major stable version comes out. This makes accidental breakage of old versions impossible, but also means only people on the latest Flutter get any bug fixes or feature improvements.
- Test older versions of stable so this doesn't happen. Each previous version adds substantially to both compute resources needed and also aggregate flake (i.e., if our flake for a given set of tests is
X%, our flake for mass testing is1-(1-X)^(#versions)%).- We could do this only for post-submit to reduce the impact, but it's still problematic.
- Note that to cover just the last two instance of accidental breakage we would need to have been testing both (stable-1) and (stable-2), which doubles our testing. Although we could do a hybrid of 1 and 2, where we test N-1 and also bulk-update minimums to N-1 on each stable release.
- Only bump when we know we need to, hope for the best, and then retroactively fix it when something goes wrong [the current de-facto approach]. Fixing could be:
- Actually restoring compatibility with the old version as a new version when easy. Although by definition we can't write tests for this approach.
- If we learn about the breakage quickly enough, retracting the old version, the re-releasing the plugin with only the constraint updated.
- Release a new version that reverts the change that caused the breakage, then release another version that re-lands it with a constraint update.
- Documenting the need to pin an old version of the plugin in the issue, and closing it. This requires anyone affected to figure out what happened and find the issue (or figure out for themselves that they should pin).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
P2Important issues not at the top of the work listImportant issues not at the top of the work listc: contributor-productivityTeam-specific productivity, code health, technical debt.Team-specific productivity, code health, technical debt.packageflutter/packages repository. See also p: labels.flutter/packages repository. See also p: labels.