microcharts-dotnet
[Question] Could you assign some additional maintainers to help get the NuGet package updated?
First of all, awesome work getting this building for MAUI. It will help with our migration.
However, it would be great if some additional maintainers could be invited, with access to build and push NuGet packages. Right now, the v1.0.0 package only supports net6.0-android and net6.0-ios, (but not net6.0 etc); while the code at the head of the repo (v1.0.1) adds these changes.
Looking at the number of forks, number of people are running into this, but rather fixing it at "the root" by getting a v1.0.1 published, we end up with ~370 forks (count at the moment of writing this).
I wouldn't mind helping out getting this building and published, as we need it at our organization, and I would rather have it published via NuGet than depending on a local build.
@follesoe The last big updates on Microcharts was from Eilon Lipton. @Eilon is the reason why there is a 1.0.0 version on nuget. Not sure why @eman1986 is clinging onto this library. If you follow the link below if will see Eilon tried to get all rights from eman to get this done, but he was unsuccessful or let's say no further interest from the owner of this library.
https://github.com/microcharts-dotnet/Microcharts/pull/334
No disrespect intended to @eman1986 but I think it's time you hand this over to someone that can at least maintain the basics or otherwise communicate that you no longer wish to maintain this so that someone else can take the lead.
The intro to Michrocharts has been stuck on this page for the last 3.5 years.
I'm honestly in favor of someone taking over, Frankly I no longer do Xamarin development or .NET development in general, so if someone wants to take it over I'll gladly welcome it.
The issue has been people have messaged me saying they want to help but then don't or they do but then stop after they achieve what they wanted for themselves.
If someone is really serious about keeping this library going, I'll happily hand them the keys.
Eilon has actually told me he doesn't want to own this library, but just wanted to help out, which has kinda been the issue at hand, no one wants to seriously take it over.
I've been asking for new maintainers for some time and have gotten radio silence, so I'd say if anyone is serious about keeping this library alive, please get with me, I took it over because it was being used by my employer and we really liked it, but then we switched to native development and no longer have the time to keep it going.
@follesoe
Thank you, @eman1986.
I greatly appreciated this library when I used it for Xamarin Forms. Currently, I have transitioned to Blazor and am utilizing a different web charts library. There is an open invitation for anyone interested to take the lead on this project. Given that the library is built on Skia and Skia is also compatible with Blazor, I believe this library holds significant potential for the Blazor, MAUI, and .NET communities.
Thanks for the reply @Pinox and @eman1986 👍
I have made a fork to get it building for .NET 8. I will consider wether I am prepared to get involved. One of the things I would probably do, is reduce the scope of the library only to support MAUI, and remove platforms such as Avalonia, Uno, Eto, Forms, etc. and only support the platforms officially supported for Microsoft through MAUI.
I'm not against that honestly, I do think you should still support Xamarin Native, but I know forms is dying off so I don't see why we'd keep it. The other ones people just added and I allowed it just to be nice and open minded, but really they're not maintainable if the people who added it doesn't stay on the project to ensure it works as intended.
I really do hope someone decides to take this project over, I'd hate to see such a promising project die off, there's not a whole lot of great charting libraries for Xamarin, I know when I found it it was the best I could find.
@eman1986 Makes sense 👍. Xamarin.iOS/Xamarin.Android and Xamarin.Forms were all end-of-life in May 2024 and are not receiving bug fixes or updates. You can still submit updates to App Store / Google Play until about ~May 2025 (based on historical data on how long Apple and Google accept updates built against older Android SDK or iOS SDK versions), but it is 100% dead after that.
.NET 9 for macOS, iOS, and Android will, of course, live-on, so packages for these platforms would make sense as .NET 9 packages.
I think the benefit of removing all extra platforms is reduced complexity in build pipelines and in test platform setup.
I have a fork that I have updated to .NET 8 and configured MAUI CI builds for. I will continue on this branch for a while and consider whether I/we (the company I work for) would be prepared to take over maintainer responsibility.
In terms of features, I think Microcharts is not lacking much, so the top priority would be to keep the builds "alive" and up-to-date with changes to the MAUI platform and third-party packages and to publish new releases to NuGet when needed.
I didn't realize they nuked Xamarin Native. Supporting what Xamarin does officially is the best idea then.
@eman1986 Agreed. I have started the work on my fork to modernize the project and support .NET 9 and the platforms officially supported by Microsoft. This means removing extra targets such as Uno, Avalonia, etc.
It would still be fairly easy to build the integration using MicroCharts.Core package, and the SkiaSharp package for each platform. But I want to reduce the surface area of this package, to ease testing when making changes (by reducing the number of platforms).
I would be willing to take over maintenance of Microcharts given you agree in the direction (and if not, I will just maintain my fork as we are already building against this internally, and my fork is publishing packages to the GitHub package repo).
See my work here: https://github.com/follesoe/Microcharts
That all sounds fine to me, I absolutely think the library itself should just support the core framework and if people want to have support for another UI Framework, they can simply use the core package and make an extension library. If you feel up to taking over the project, I have no objections to giving you access to the repo as well as the nuget store.
Sounds good, @eman1986. Go ahead and add me. I will complete the work on my fork before issuing a PR when I am done and merge that into this repo.
I will work towards a v2.0.0 release, removing obsolete platforms and upgrading SkiaSharp v3.
As we rely on this package at work, I don't mind taking on the maintainer's responsibility. The library is stable and functional, so the main goal will be to keep up-to-date with .NET releases and changes in external dependencies.