Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cronet_http_embedded] incompatibility with newer versions of cronet_http #1047

Closed
problematicconsumer opened this issue Nov 16, 2023 · 11 comments · Fixed by #1111
Closed

[cronet_http_embedded] incompatibility with newer versions of cronet_http #1047

problematicconsumer opened this issue Nov 16, 2023 · 11 comments · Fixed by #1111
Assignees
Labels
package:cronet_http type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@problematicconsumer
Copy link

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.

@problematicconsumer problematicconsumer added package:cronet_http type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Nov 16, 2023
@AlexV525
Copy link
Contributor

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

@brianquinlan
Copy link
Collaborator

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
Copy link
Contributor

AlexV525 commented Dec 4, 2023

  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?

  1. 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
Copy link
Contributor

AlexV525 commented Dec 7, 2023

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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.

@AlexV525
Copy link
Contributor

Could we transfer the package to our publisher (flutter.cn)? If it's too risky to add me to the transfer, I can add you first to do this.

@brianquinlan
Copy link
Collaborator

I've generated a new package:cronet_http_embedded release. I'll leave this issue open until we figure out what publisher to use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:cronet_http type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants