Lower the needed UWP Version

[inforithmics]

When Popup functionality was added to Xamarin Community Toolkit. The UWP Version was raised from 10.0.17763 (1809) To 10.0.19041(2004)

Because I need to support at least Version 1903 some others need to support 1809 Because 1809 is a Windows LTS Release I cannot use an official Xamarin.Community.Toolkit package greater than Version 1.0.3.

I Have made 3 Pull request to adresse this Problem.

Lower the UWP Version to the lowest Version that supports all used features.

#1684

This is the smallest Pull request, it simply lowers the UWP Version to 18382 (1903) (There all Flyout features that are used are
present for Popup).

Reintroduce the UWP Version 17763 / 1809

#1247

This pull request adds an additional Target with the Version 17763 / 1809 and handles the some things that are not available on 1809 differently than the 10.0.19041(2004) Target.

#942

This pull request lowers down the Target to 17763 / 1809 and uses UWP features to detect if a feature is availble on the Target machine.

So I wanted to discuss here how Xamarin Community Toolkit should progress here. Because MAUI is available at the earlist in Spring 2022.

When there is no interest in integrating one of the 3 Pull Requests into Xamarin Community Toolkit. Than I will keep them open to get the newest Xamarin Community Toolkit packages With this specified fixes.

[bijington]

We ultimately need to make a decision on this topic to give you an answer and prevent you from having to keep these PRs up to date without anything happening. The following documents my thoughts on this as I try to point out the positives and negatives of these proposed changes. I am also fairly new to this team/project so please forgive me if I have missed any details.

Some initial points

As documented here Version 1809 is still running under mainstream support until 2024-01-09. That said there is an important point documented here pointing out that this issue is likely to happen given that LTSC builds do not receive new feature updates.

The Long-Term Servicing Channel is not intended for deployment on most or all the PCs in an organization. The LTSC edition of Windows 10 provides customers with access to a deployment option for their special-purpose devices and environments. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. These devices are also typically not heavily dependent on support from external apps and tools. Since the feature set for LTSC does not change for the lifetime of the release, over time there might be some external tools that do not continue to provide legacy support.

Weighing things up

Positives

• Increased coverage of targeted devices for consumers
• Allow for bug fixes to be provided for older frameworks/apps/devices
• Fits with the plan to only release bug fixes going forward on this toolkit

Negatives

• Potential increase of maintenance effort
• An area that I believe a majority of the maintainers do not have a huge amount of experience
• (Multi-targeted Multi Target UWP to 1809 and 2004 #1247) Extra testing effort required to check the stability of the changes on each supported platform

Summary

This is a difficult one to make a decision on! I currently feel that the team does not have any extra bandwidth to take on more effort but of course this is just my opinion and this is an open discussion but in argument to that if community members have put the effort in to testing this and proven it behaves then I don't see that there should be too much effort in the short term to take one of the PRs. Worst case should things start to break we could reverse out the change and move to a more modern minimum version.

@inforithmics you have clearly put some effort in to creating the PRs, how confident are you that this won't break things in terms of other functionality provided by the toolkit?

[inforithmics]

The pull request that lowers the Target to 1903 ist certainly the lowest Risk. Because it ist only one framework Version and has not many changes. It is what I currently use. And it only needs to be Tested once. And I don't think that this could introduce breaking changes. The other pull request ist much riskier because I needed to Change Code by conditional compiling. So this needs to be Tested two times. Maybe a bit much for a Target that ist not used so much. And in Maui this isn't needed anymore.

[inforithmics]

So in conclusion I'm pretty confident that #1247 won't break anything. The other pullrequest I'm not so sure about.

[bijington]

So in conclusion I'm pretty confident that #1247 won't break anything. The other pullrequest I'm not so sure about.

Ok thanks. I'll aim to discuss this with the team so we can make a decision on what to do.