[cronet_http_embedded] incompatibility with newer versions of cronet_http

[0xConsumer]

cronet_http README states that cronet_http_embedded is the same library with Cornet bundled. But it hasn't been updated in some time, and these have different interfaces. Since some Chinese manufacturers don't have Google Play Services included, it's vital to bundle cornet.

[AlexV525]

@brianquinlan This is it. As we discussed in #853, we may need to setup automated publishing to sync packages.

[brianquinlan]

I'm not sure how to proceed with package:cronet_http_embedded.

Right now there are a few problems:

1. Right now I can't run the cronet_http tests against that package because the package name is different
2. The example on pub for package:cronet_http_embedded is actually for cronet_http
3. AFAIK, I can't enable the "dart-lang/ecosystem/.github/workflows/publish.yaml@main" workflow because publishing package:cronet_http_embedded requires an additional step.

Maybe someone should create their own repo for cronet_http_embedded and publish from there?

[AlexV525]

1. Right now I can't run the cronet_http tests against that package because the package name is different
2. The example on pub for package:cronet_http_embedded is actually for cronet_http

If we skip the package name modification for tests, does it sounds good?

3. AFAIK, I can't enable the "dart-lang/ecosystem/.github/workflows/publish.yaml@main" workflow because publishing package:cronet_http_embedded requires an additional step.

We can consider adding pre-submit script run support to the action.

[AlexV525]

After investigating all mentioned concerns, I can tell it's easy to verify all circumstances and make integrations. I'm currently working on it. @brianquinlan

[brianquinlan]

I would strongly prefer if someone else could take over the maintenance of package:cronet_http_embedded.

I plan on releasing package:cronet_http version 1.0 soon under the dart.dev publisher. With that, I'll be committing to high SLO support for package:cronet_http. I don't have much a lot of bandwidth to make the same commitment for another package.

I should be straightforward to fork dart-lang/http and publish from that repo. I'm willing help if someone volunteers.

[AlexV525]

I would strongly prefer if someone else could take over the maintenance of package:cronet_http_embedded.

I plan on releasing package:cronet_http version 1.0 soon under the dart.dev publisher. With that, I'll be committing to high SLO support for package:cronet_http. I don't have much a lot of bandwidth to make the same commitment for another package.

I should be straightforward to fork dart-lang/http and publish from that repo. I'm willing help if someone volunteers.

Could we use labs.dart.dev as its publisher? If not, we (@cfug) can help with the management as we already have dio as our package. But leaving them in separate places will cause gaps between publishing, or we need a notification mechanism to be informed about new version releases of cronet_http to automate our tools.

[brianquinlan]

But leaving them in separate places will cause gaps between publishing, or we need a notification mechanism to be informed about new version releases of cronet_http to automate our tools.

Would some automation like https://github.com/marketplace/actions/merge-upstream help?

[AlexV525]

Would some automation like https://github.com/marketplace/actions/merge-upstream help?

I'm not sure and not in favor of it. I'd prefer to understand the circumstances of publishing this under labs first.

[brianquinlan]

The idea behind labs is that is for limited duration experiments - packages should graduate into another publisher of be discontinued (like https://pub.dev/packages/wasm for example).

Could you use a service like One Pub
https://onepub.dev/search?query=cronet_http

Would it make sense to keep the code for package:cronet_http_embedded where it is now but for someone other than me to publish it?

I hope that package:cronet_http will have fairly infrequent releases.