Closed scheglov closed 2 months ago
Thanks! Unfortunately, applying this will be a bit of a headache. When possible, drift strives to support the two latest Flutter/Dart releases to reduce churn for users. Due to the _macros
dependency, version 6.9.0 of the analyzer
package is not compatible with any stable Dart release at the moment.
So applying this means that I have to change our CI to run with a non-stable Dart SDK and it forces all drift contributors to switch to those newer versions as well. I don't want to stand in the way of Dart changes landing, but deprecating and then removing analyzer APIs without at least one stable SDK release in between is a pretty fast turnaround and will probably cause pain for other Dart projects as well.
So if removing enclosingElement
is required to land other important analyzer changes, I'll take the hit and get this working and released. But it is hard for me, drift contributors and also users who won't be able to use the latest drift version until upgrading their SDK. But on the off chance that removing enclosingElement
is not a blocker for analyzer development, is it possible to land these breaking changes after a stable SDK release?
I need a branch in drift
repository to point at it when rolling drift
into Google.
And this PR should be merged into this separate branch.
This means that Google will not get update that are made to the main development branch.
But I think we are fine with it for some time.
Merging this into another branch sounds reasonable 👍 I'll get that set up and also fix the CI to use a dev SDK there.
I have merged your changes (and also fixed other uses of deprecated analyzer APIs we have due to compatibility requirements) in c6cf2e6790950cfc6039afe01ffcacbee3b37606.
That commit is on the dev-sdk
branch merged off the latest-release
branch you've previously used as upstream. Let me know if there's more for me to do here.
Thank you!
Prepare for https://dart-review.googlesource.com/c/sdk/+/385100