Remove Xamarin Forms #2251
Remove Xamarin Forms #2251
Conversation
|
Is this a change for Mapsui 5? |
|
I fully agree that this should be done at some point, but isn't it a bit early? (This question also depends a bit on the roadmap of further releases: When do you expect to release Mapsui 5? And will there be further stability releases for 4.x?) Xamarin will still be supported by MS until May 2024, .NET 6 and 7 have been a pretty rough ride so far (with plenty of quality & stability issues) and .NET 8 is not even officially released ... https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin |
|
Note: The nuget download numbers for 4.0.0 are still in the same ballpark for Maui and Xamarin.Forms:
I'm sure there are plenty of projects that haven't completed the transition from Xamarin to MAUI. Removing Xamarin.Forms somewhere in the course of 2024 is completely sensible IMHO, but right now? Might leave many of your users dumbstruck. Just my two cents. |
|
@charlenni @janusw Removing Xamarin.Forms is part of v5. This was added in the roadmap on April 4th this year https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin. I think this project has a lot more potential if some fundamental changes were made. I want to move forward way faster than we are now going. When I have a few hours a week I want to spend it improving Mapsui instead of figuring out why it is not building this week. My plan is to release v5 soon, within months, but we could still release patches for v4. Microsoft is supporting Xamarin until May1st 2024, they say, but since January 5 2021 (that is almost 3 years ago) they have only released patches on 5.0.0. At the same time they have 783 open bugs. That is not a lot of effort for a billion dollar company. We are just an open source project with no income from this project, I don't think we need to do much better than Microsoft. Still, v4 is the supported version right now, clearly now v5 is not yet released, and perhaps to some extent also after the v5 release. But mostly, I don't really know what supporting means, because I don't want to promise anything, there will probably be patches, that's all I can say. So, how to continue: My plan is to keep the patches small. This is not only because I do not want to put too much effect in them, but also to reduce the likelihood we introduce new bugs. Most people that have an application working with 4.1 just want stability. v4 is now in the develop/4.1 branch. There are two PRs now in master that I think should be released as 4.1.2. You could help by turning them into PRs for develop/4.1. |
|
About the download numbers. What I see after a new release is that in the first few days there is a high number of downloads for most packages. I suspect these are local nuget repositories that automatically download the new versions. After a few weeks the download number start to stabilize. So, you need to look at the older packages to get a better impression. For 4.0.0, released 5 months ago it is Maui: 1996 versus Forms: 1496, so you could say it is in the same ballpark, but for 4.10 it is Maui: 600 versus Forms: 160, so that already starts to differentiate. If we check 4.1.1 in few weeks I expect the difference to be bigger. But for the most part my argument is easy to keep up with the kind of support that Microsoft offers, if we release 3 patches before May 1 we will be doing better than they are. |
|
Thanks for your detailed reply, @pauldendulk.
True. In fact I have seen this, and maybe I should have spoken up earlier, but actually the roadmap does not mention any concrete dates. Earlier major releases of Mapsui had a cadence of 1 - 1.5 years, so I was expecting 5.0 around mid-2024. I don't see a problem with removing Xamarin support at that date. But I do fee like it's too early doing this right now (in particular if 5.0 is supposed to be released sooner).
To be honest, I don't have the feeling that Mapsui's pace of development is too slow (you and @inforithmics are both doing an incredible amount of work on the project). To the contrary, I think Mapsui is a very active project with lots of changes. This is great, but it can also lead to a different problem: stability (both in the sense of stability of interfaces, but also regarding software quality). Of course people might have very different requirements regarding pace vs stability, and indeed I was for quite some time living on the bleeding edge of Mapsui myself, but by now my use cases have matured a bit and I'm in need of a stable version that is more-or-less bug free, instead of chasing moving targets. Therefore stability is more of a concern to me at present than pace of development. And I'm sure many people have similar requirements.
This almost makes me feel like I need to defend MS (although I'm usually more in the position of criticizing them :D) ... Yes, the pace of development for Xamarin is certainly quite low by now (with the focus having shifted to MAUI). Basically no new features are implemented, and only the most important bugs are being fixed. BUT: It's very stable, and at least MS is making sure that people can continue working with it until MAUI is stable enough (which is taking more time than we all would prefer).
I don't think you need to do 'better' than Microsoft. I only think you should not drop Xamarin too soon, since many people may still need to rely on it. Looking at the total download numbers, it's Mapsui's most popular platform after all. Also I wonder whether removing Xamarin would gain so much in terms of getting rid of maintenance overhead. It's there, it's working, it even shares most of the code with MAUI (which will stay). A lot of 'exotic' platforms were added to Mapsui recently (Avalonia, Uno, Eto). I don't think any of them has reached the number of downloads that the Mapsui.Forms package has. Why are they given more priority then?
Fully agree. I think that's a good idea.
Here I don't agree. I would put it the other way around: The people that want stability have probably not even upgraded to 4.1 yet (including me). What they'd need are further 4.0.x releases that fix the worst bugs without the risk of adding further bugs. |
|
I am not criticizing Microsoft, in fact I think they made the right decision to leave Xamarin.Forms behind and move on to Maui, but I am comparing what we do to what Microsoft is doing. Our master branch should be compared to Maui and our develop/4.1 branch should be compared to Xamarin.Forms. Dropping Xamarin.Forms from master is like Microsoft dropping Xamarin.Forms from their main development when going to Maui. The difference with Microsoft is that we were adding new features to Mapsui Xamarin.Forms years after they dropped it. About the pace of development. This is how open source software works. I don't assign people to tasks, things just happen. People contribute whatever they are interested and I thank them for that. In larger projects this problem, of stuff happening on all fronts, will be even bigger. The way to go about this is by working in different branches, but this comes at a price as well, this is why I would personally have preferred a longer period where we could stay on one branch. When I decided to move master to v5 this was also to prevent breaking changes and bugs in v4.
The problem is mostly in the tooling. Xamarin.Forms and Uno UWP relied on msbuild, and old nuget packages. We needed hacks to stay compatible with old and new. Those hacks work for a while but can break after an update. We had weird bugs in newer versions of visual studio. This is not just theory, I actually have to spend a lot of time on it. In master we will now move to .NET 6 and compile with
Avalonia and Uno are not exotic. Their combined downloads for v4.0.0 are 1489 (884+605) while Xamarin.Forms has 1496, and I expect them to grown. Then again there really is a price in supporting more. I think we should support less and support it better (this does not only apply to platforms). This is also why I want to move more of the platform specific code to shared code, so the cost of maintaining an extra platform is low. I did not like having to go to 4.1.0 instead of 4.0.1, but this was a consequence of the ongoing changes. The only way to prevent this would have been to split v4 and v5 even earlier. |
Ok, point taken. I have been cursing the awkward msbuild myself a couple of times, and I am also quite familiar with weird VS bugs (in particular on MacOS, and in particular with pre-net6.0 or mixed projects) 😆 Moving to |
|
So, trying to wrap this discussion up: If you're dead-set on removing Xamarin.Forms on master now (I can see your reasons, but I'm not quite happy about the timing), then my suggestion is that we (as a developer community) should at least make sure that Mapsui 4.x keeps being maintained for a while and will receive some bugfixes. However, I don't expect you, @pauldendulk, to take all this maintenance burden on your shoulders alone. I can offer to act as a maintainer for Mapsui 4.x for a while (doing backports of bugfixes and preparing releases). Note: Since I am currently blocked by one or two rare bugs from updating to 4.1, I'd suggest to set up a develop/4.0 branch, backport some low-risk fixes there and release a 4.0.1 (and maybe 4.0.2 and 4.0.3 afterwardss) Maybe this way we can achieve a compromise between fast-paced development and stability that everyone can live with. What do you think, @pauldendulk? Does anyone else have an opinion on this topic? |
|
@janusw It is bad enough we have to work with two branches. I don't want to introduce a third. The changes from 4.0 to 4.1 are not dramatic. I am sure we can resolve the problems. Also, it is important to solve the problems, because if it is a bug for you it is also a bug for others and the majority of users will be using 4.1. Is this the problem you are referring too? #2197 |
That's why I offered to help with the maintenance work. But anyway ...
Yes, that is the main showstopper for me right now. If it can be solved and I can move to 4.1, even better. (But there might possibly be another issue, have to check 4.1.1 again). |
☝️ @inforithmics, @charlenni ? |
|
@janusw asked, so I will give my comment here. I lost the overview over the project in the last month. There were so many different PRs with many commits, most, for me, not very clear, what they all about. And to less time. It is @pauldendulk project. So he has the lead. I wouldn't have made a 4.1 at all. And when, then there should be a 4.0, a 4.1 and a 5.0 branch. But the most important part for me is, that there isn't a clear plan where to go with the next versions. Removing platforms is ok, when they obsolete, but that isn't an improvement for the user. And integrating MapView options in MapControl is a documentation problem. MapView was always a convenient wrapper around MapControl, so that Mapsui could replace the Xamarin.Forms MapView. So, I'm missing the idea behind 5.0. If it is removing old platforms and bring Mapsui to .Net 6, then this is ok. But do this and add some changes to RasterTileLayer and some changes here and some there, then it looks like a project without plan. And it is nearly impossible to help. For me, it looks like the only improvement is to have more platforms Mapsui runs on. And this is the most time-consuming problem, because I don't know anything about these platforms. So how should I support them? And a waste of time, that could be used for more relevant things, like ordering of layers, rendering/drawing behavior or speed improvements. I would prefer a clear plan, what to change in Mapsui. This should be set before starting with a new version. Then it is clear, when Mapsui 5 is ready (all parts of the plan are fulfilled) and when to start with the next version. The next is, that this plan should have many small points when you expect to have many small PRs. If there is a point "MapView", then this is too unspecific and big. If you don't like MapView, then remove it. There isn't anything special, that couldn't reach with MapControl too. You have to say, which parts of MapView are helpful and must implement back into Mapsui. And I would prefer a discussion about the above points. Software development is only a hobby for me. So my ideas not always the best. Little chaotic, but I think, you could understand, what my opinion is. |
|
@charlenni Thanks you for you feedback! Systematic work towards a next milestone is not so easy in an open source project for many reason:
That said, we could try to improve it, and your message motivated me to try. Perhaps I should look into the github project thing. Earlier this week I was looking into the 'help-wanted' issue tag that is used in Microsoft projects, as a way to indicate that people could work on it. The System.Drawing.Color issue that I created this week was intended for that. It is a fairly big task but I expect it does not need a big design change. #2260 I also would like to promote this issue. Which I think will be the biggest in improvement in the history of Mapsui , past, present and future. It will save us and our users loads of time. It is writing the logger to the map canvas. Should be configurable, but default on for developers. It would have saved me an hour today. #1579 |
|
@charlenni More follow up on your post later. |
|
What you say is mostly right. People are coming and going. You could not rely on them. But it seems, that some people are more interested in this project than others. And for them, there should be something to work on. I'm one of these peoples, but I have no plan what to do. I assume, that I could solve any problem with making a special map with Mapsui. And I don't do anything with Mapsui for an own project (beside the vector map). So for me, it would be helpful to have a list of things to do. Each time I had time, I could look into this list and try to solve a problem. The problem you mentioned in #1579 is such a thing. It is not too big and is comparable to the performance widget. Or the change to System.Drawing.Color. Seems not to be a big thing too. So make a list of things, that are not very complicated, but time-consuming for you. If the screen logger is ready next week or in 2 months, isn't very important. But if it is done, Mapsui is again a little more helpful. You can plan the MapView changes. The most important part of MapView is, that you could use WGS84 coordinates in Mapsui. That format is, what users know. I would say, explaining the coordinate system of Mapsui better and explain, how to convert WGS84 to Mapsui and vice versa is the biggest part of this integration. |
|
sorry, closed by accident 🙈 |
|
Thanks for the comments, @charlenni (although most of them actually do not concern the topics that I asked about, namely the removal of Xamarin.Forms and the tension between progress and stability).
This matches one point I made: There is a lot of progress, which is great, but it comes at a price. My main concern is not losing the overview, but the problem of instability: A very high rate of modifications will potentially introduce many bugs, keep changing the interfaces and make it harder for people to use the library.
For me 4.1 was also a bit surprising, since it deviated from the previous release scheme (one major release on the timescale of a year and many beta tags in between). In principle I think that more and smaller releases are better than fewer larger ones, but there should always be some stable 'LTS' version for people that use the library in a productive environment and need a stable and bug-free version (instead of the latest bleeding-edge features). Right now one only has the choice between 'unstable' and 'extremely unstable' (and 'very outdated').
At least @pauldendulk has some sort of roadmap, which sets the general theme and ideas for the next release. Not all projects have that. Well, and after all, this is an open source project. Maybe you need to adjust your expectations a bit and realize how such projects usually work (in particular if they're community-driven and not backed by a commercial company): There is no plan and no one who tells you what to do and what to work on. There is just a loose collection of contributors with varying degrees of commitment and widely differing goals and interests. Everyone contributes to the big picture by scratching their own itch, which ideally results in a product that works well for everyone. I'm a bit puzzled why you are complaining that no one tells you what to do. This leaves you the freedom to choose by yourself which improvements are the most important to you and work on those. Or, if you cannot agree about the fundamental direction of progress with the other contributors/maintainers: Fork the project or start a completely new one, and do your own thing (all by yourself or with a different set of contributors). |
One thing I could improve is to be more clear about the status. The summary of the status right now is:
I will add the current status to the roadmap page. |
|
I looked into github Projects but there is nothing there that would help us now. I will now simply use milestones to assign issues to a version. I announced it here: #2278 There is more I need to specify and I like to explain more about my general ideas but this is it for now. |
No description provided.