Release version with analyzer's Element2 APIs

[srawlins]

In order to migrate downstream packages like drift_dev, we need a release of source_gen that is compatible with Element2, like spanForElement2.

[jakemac53]

Afaik we have been trying to avoid propagating the *2 pattern out to the other packages. So the goal is to just do a breaking change that just immediately swaps to the *2 APIs, as opposed to doubling the API surface of this package.

This is also what package:builds as a whole is (at least trying) to do.

It is very messy though, internally we do actually have both APIs at once because we have no alternative, and the world is also simpler there so there isn't as much downside. cc @scheglov what is the status of the internal migration?

[srawlins]

Either way is fine by me. Consumers like drift_dev can bump to a new major version when it is released and use Element2 in all the existing APIs.

[jakemac53]

Either way is fine by me. Consumers like drift_dev can bump to a new major version when it is released and use Element2 in all the existing APIs.

Fwiw iirc package:builds has a branch which does use the new APIs (and this is what is in google3), and the plan was that any package that is merged internally would have a branch also that depends on that, which allows us to migrate the internal world prior to publishing the breaking change externally.

[jakemac53]

Oh, and this package does in fact have a corresponding branch, https://github.com/dart-lang/source_gen/tree/analyzer-element2

[scheglov]

I don't know exactly how many, if any, internal generators we still have to migrate.
@stereotype441 posted a few days ago that there was a small handful.
And @srawlins actively worked on them, so I'd not be surprised that we have zero.
But I did not check.

[srawlins]

the plan was that any package that is merged internally would have a branch also that depends on that

This would include drift_dev?

[srawlins]

which allows us to migrate the internal world prior to publishing the breaking change externally.

What is the benefit of this?

[jakemac53]

Internally we have a one version policy but we can't realistically migrate all internal code at once. This is why analyzer has no choice other than the *2, *3, etc APIs for migrations.

So, we get an incremental internal migration because its a requirement, and externally we just rely on pub solves and don't double the API surface.

[srawlins]

I don't see what the internal migration has to do with the pub publish.

If you publish source_gen 3.0 today, without doubling the surface area, only relying on Element2, and you keep pushing the analyzer_element2 branch internally, then you comply with one-version, and you continue to migrate incrementally internally.

[jakemac53]

If you publish source_gen 3.0 today, without doubling the surface area, only relying on Element2, and you keep pushing the analyzer_element2 branch internally, then you comply with one-version, and you continue to migrate incrementally internally.

We are using the internal migration to validate the new APIs, and just generally don't want to publish externally while in this limbo state since we can't easily roll that back.

[srawlins]

We are using the internal migration to validate the new APIs, and just generally don't want to publish externally while in this limbo state since we can't easily roll that back.

Sounds good.

[srawlins]

Almost everything internal using source_gen has been migrated. There is one package that requires #738.

In simolus3/drift#3492, @simolus3 was able to migrate almost everything in drift_dev.