📣 This project is no longer maintained

[stuartmorgan]

This project is no longer maintained, and will not receive further updates. We invite anyone interested in coordinating the establishment of a community-maintained fork to discuss below.

[fzyzcjy]

@stuartmorgan Thanks and I totally agree.

So, anyone who are interested in maintaining it, just ping me and I will add the permission to the fork

[FeodorFitsner]

Those closed PRs referenced in this issue - should they (some of them) be integrated (already integrated?) into the fork? Do all of them make sense?

[atn832]

Until the community agrees on a specific fork and publish a new package, a quick workaround to get the latest updates is to set up a dependency override:

dependency_overrides:
  # Keep until https://github.com/google/charts/issues/798 is resolved.
  charts_flutter:
    git:
      url: https://github.com/fzyzcjy/charts.git
      ref: master
      path: charts_flutter

I use @fzyzcjy's because there's a few commits I wanted in my project. One can use any other fork.

[fzyzcjy]

@keeganskeate You are welcome. Anyway, I will not have a ton of time maintaining the fork (given so many open source libs that I already need to maintain), but I use it in my own app so at least I can guarantee it is not stale.

[stuartmorgan]

@stuartmorgan, do you have any concerns about Flutter developers depending on this fork?

I'm not sure why this question is addressed to me; please see my comment above.

[keeganskeate]

The main reason that I asked you @stuartmorgan is because I thought that perhaps you may be a good judge if this new fork may be safe to depend upon or not. Would you ever depend on the fork by @fzyzcjy in your own work? The discussions above, including your comment, suggest to me that Flutter developers should depend on @fzyzcjy fork moving forward. This raises a concern to me and I thought that it would be responsible to raise my concern. If I am off-base or misread the discussion, then I apologize.

[fzyzcjy]

@keeganskeate By the way, I am quite curious why you are so skeptical about me :) Have you ever used open source libraries from non-big-companies before?

[josxha]

@keeganskeate I think you need to revisit the previous conversation. The issue was kindly opened to encourage a conversation about further maintenance.

Nowhere does it say that you should use @fzyzcjy's fork or that it is being handled as an official successor from Google's perspective. @fzyzcjy has been the only person since a month to offer to keep the project usable for the future. You might as well make and maintain your own fork - that's how open source works. (:

In addition, stuartmorgan has made it clear that Google's maintenance on the project has been discontinued. So you can guess that they won't do a code review on forks and won't make a recommendation about what version to use.

There is no longer a maintainer of the packages in this repository, so it's up to the community to decide what (if anything) to do next.

[stuartmorgan]

The discussions above, including your comment, suggest to me that Flutter developers should depend on @fzyzcjy fork moving forward.

I'm not sure what in my comment you are reading as an endorsement of any specific package, but that's not my role here.

[stuartmorgan]

However, I interpret @stuartmorgan's comment, "A single fork with multiple owners would be more likely to be sustainable than multiple one-off forks by individuals." as implying that @fzyzcjy's fork should be used.

I've already explicitly said that my comments here are not intended to endorse any specific package. Please don't continue to put forward interpretations of my comments that I've said are not accurate, as it may mislead others reading this thread.

My comment means exactly what it says, and it didn't say that anyone should do anything. As I also said above: "it's up to the community to decide what (if anything) to do next". This thread was created simply because without a centralized place for discussion, complete fragmentation would have likely been the only plausible outcome, whereas a discussion space allows for the possibility of other outcomes.

@stuartmorgan your hand's off approach [...] is concerning to me. I believe that software developers have responsibility for the software that they create.

I'm not creating any software here, I'm moderating a discussion thread. Any forks would be the responsibility of the developer(s) creating those forks.

For those who run into the same concerns as I, then I am exploring the fl_chart package. [...] [I] will defer to the community on how best to use 3rd party Flutter packages, such as which charting packages are good to use.

If you would like to discuss possible alternative packages to use as a client, please consider one of the resources listed at https://flutter.dev/community#community-grid. That discussion is not on topic here, as this thread is for potential fork maintainers. Per the initial post:

We invite anyone interested in coordinating the establishment of a community-maintained fork to discuss below.

[stuartmorgan]

(I'm going to hide several comments above as off-topic. Anyone with questions or concerns about using any given fork should follow up with the developers of the fork in their own repository, and/or with the community in general discussion space, as they would with any other package in the ecosystem.)

[FeodorFitsner]

We've been in search for a Flutter charting package for our project and indeed the current choice is limited to charts_flutter (this project) and fl_chart. There is also "syncfusion" package, but it's not open-source.

Google charts is a great piece of software and, at a glance, more feature-rich than fl_chart and it would be sad to waste it.

The project (fork) would receive more trust and visibility if hosted under an organization, and it will be more convenient to work with multiple contributors too.

What about moving the project under Flutter Community org? Is it a good candidate for it? Who should initiate the transfer?

[talamaska]

Those closed PRs referenced in this issue - should they (some of them) be integrated (already integrated?) into the fork? Do all of them make sense?

From what I see some of them do make sense. Some of them are fixing issues with using old dart lang. Some are maintenance things and some are adding features. i personally would love to see the proper custom labels implementation, which i saw somewhere in the issues. It was using private apis, which we can now make public, since we can now fully control what is exposed and what not. In some sense, google dropping the support gives us freedom of adding features quicker and fix issues quicker. Although it really leaves a bitter taste, since the company is using it's own repo with some of the fixes we need to implement alone, because Analytics app is still using the library. For me this not quite a good signal to the community and suddenly brings a question why google can support the js library but not the flutter one.

[stuartmorgan]

Proposals to integrate PRs from this repository into any given fork should be made in the fork's repository, rather than here, since it would be up to the maintainer(s) of that fork to decide what to accept.

[stuartmorgan]

What about moving the project under Flutter Community org? Is it a good candidate for it? Who should initiate the transfer?

Neither this project nor the existing packages would be transferred to another organization. If the maintainer(s) of a fork want to pursue that route, they would initiate that process with their repo/packages.

[juliansteenbakker]

I needed a stable version of this package so I've forked this project and published it under the name community_charts_common & community_charts_flutter. In this version i've fixed several outstanding problems so that it will run stable on the latest Flutter version. This version also fixes some bugs that were present in other forks like @fzyzcjy that caused pie charts to not load.

There are still some tests that needs to be migrated to null-safety, but I'm open for PR's.

[stuartmorgan]

This repository will now be archived. See comments above for some possible forks to consider, and for any further discussion of new forks consider general Flutter discussion resources such as those listed at https://flutter.dev/community#community-grid.