Expose FrontendServerDdcLibraryBundleStrategyProvider, make vm_service_interface a min constraint, and publish 24.3.0

[srujzs]

This is needed to expose this provider to flutter_tools. I expect this to be continuously revised however. @bkonyi, should this be a prerelease that flutter_tools can use instead of some sort?

[bkonyi]

If we get into the business of using pre-releases in flutter_tools we'll have to pin DWDS and manually roll it, which is a minor annoyance at best. Also, if this interface is going to be changing in a breaking way, we'd have to respect semver and do a major version bump.

How much do we expect this interface to change? If we don't expect many breaking changes, we can just include this in a standard release. Otherwise, I'd prefer we get further along on the interface design and rely on local testing with the flutter_tool if that's at all possible.

[srujzs]

It's actually the nested interface that would be breaking (DdcLibraryBundleStrategy). I can think of only one change currently where I'd want to remove support for (loadModuleSnippet).

In that case though, I'd want to modify LoadStrategy in general to not have a loadModuleSnippet member, so we'll need to do a breaking change regardless of the state of DdcLibraryBundleStrategy.

What do you think about doing all the breaking changes in a single release once we get hot reload working? We can push forward with this minor release (and further minor releases) until then. I'd like to avoid keeping too many changes working only locally with flutter_tools.

[bkonyi]

Yeah, if we can do all the breaking changes in one release that would be ideal. I just want to avoid having significant churn in public interfaces that require breaking changes to be managed downstream.

[srujzs]

I believe this should be okay to publish then.

FYI, the dry-run has a warning:

  Package validation found the following potential issue:
  * Your dependency on "vm_service_interface" should allow more than one version. For example:
    
    dependencies:
      vm_service_interface: ^2.0.1
    
    Constraints that are too tight will make it difficult for people to use your package
    along with other packages that also depend on "vm_service_interface".

Do we want to avoid pinning and instead use ^?

[bkonyi]

Do we want to avoid pinning and instead use ^?

Yeah, giving it more thought we should be safe to no longer pin this.

[srujzs]

Done, thanks! PTAL

[srujzs]

@bkonyi

Okay, I believe webdev should be updated in a follow-up PR instead. This is the cadence this package seems to use before the latest release and it seems to line up with the package validation errors I was seeing (where webdev couldn't use the latest package because it hasn't been published yet) e.g.:

• dwds 24.1.0 and webdev 3.6.0
• dwds 24.0.0 and webdev 3.5.0
• dwds 23.3.0 and webdev 3.4.0

I don't quite understand how you managed to do both in one PR with the latest release :D, but this way makes the bots happy. I'll submit once CI is green again and upload a PR updating webdev.

[bkonyi]

@bkonyi

Okay, I believe webdev should be updated in a follow-up PR instead.

SGTM!

I don't quite understand how you managed to do both in one PR with the latest release :D, but this way makes the bots happy. I'll submit once CI is green again and upload a PR updating webdev.

I'll be honest, I don't remember what I did there... :)