Consider adding policy for "breaking" changes to hints/lints

[davidmorgan]

In theory hint/lint changes are not breaking, but in practice they are, since checking analyzer output is a standard part of builds / travis checks. (google3, flutter, ...)

We should figure out if it's okay for an SDK release to turn travis builds red for hints/lints, or if these should count as breaking changes, or if there is a good middle ground.

[bwilkerson]

@pq FYI

[pq]

See also: dart-lang/linter#1225.

I agree that what we're doing is a little Wild West and some guidance would be good. How would we treat rolls differently if we characterized, for example, tightened lints (such as the recent change to flag type names in catch clauses) as breaking?

Thanks for kicking this off!

[pq]

Popping up, regardless of what a breaking policy would say, it would be great if we had a better process for vetting lint and analysis changes in the SDK. I'll follow-up offline with ideas on that.

[srawlins]

I documented a proposal a while ago at dart-lang/linter#1225. We should probably just have a proper document in the repo.