Windowscommunitytoolkit: [Discussion] Bump Minimum Version to 1809

[michael-hawker]

We're going to be updating our Target to 19041/19042 for our 7.0 release (depending on SDK timing in the future as that's TBD).

However, we're still currently targeting 16299 to make it easier for developers to target projects back to that platform. This does add a lot of complexity for newer properties like CornerRadius, ComboBox IsEditable, TextBox Description, etc... that we want to use in the toolkit.

According to AdDuplex here, 95.5% of folks are running on 1809 (17763) and later, based on store apps usage.

1809 is also the latest LTSC version for extended support.

WinUI 3 currently does support 1803 and newer, so it'd be a bit weird for us to be higher than that, but I think we gain the benefit of their expanded reach when we release "8.0" later on top of it.

For now, I think it'd simplify our development process and remove some conditional XAML (which would prepare us better for WinUI 3) to move our minimum target to 1809.

Any thoughts or concerns on this? @azchohfi @simeoncran @vgromfeld @Sergio0694 @marb2000 @skendrot

[michael-hawker]

This would also help us with some of the issues we've been facing due to https://github.com/microsoft/microsoft-ui-xaml/issues/2556, as I didn't notice the SDK bump helping, but was also trying on a weird property (IsEditable) which exists just behavior change on older versions.

[azchohfi]

I don't think that conditional XAML would make much sense to use any of this properties on WinUI3, since everything will be lifted and available (that is one of the value propositions of it).

However, we're still currently targeting 16299 to make it easier for developers to target projects back to that platform.

@michael-hawker Sorry but, why is that the case?

[michael-hawker]

@azchohfi for WinUI 3 I was saying by bumping our min version we'll be removing a lot of conditional XAML in the Toolkit, so we'll be one step closer as we wouldn't need it in WinUI 3 later anyway.

However, we're still currently targeting 16299 to make it easier for developers to target projects back to that platform.

As for this, if we have a min of 1809, an application developer can't go below that as their minimum target and include the Toolkit. Otherwise the tools won't load it, even if you use conditional XAML to try and not use Toolkit components when the app is running below that. It's seems like something that was missed as part of the build system to support having an app min lower than any include library.

So, up until this question, we've left the minimum down so that application developers can target anything in-between 16299 and now, but I think for the project maintenance, it'd be easier to bump it up now for 7.0. That also means we still target a LTSC release, which I think is a good bar to keep at least, as that's probably what most folks would be min targeting as things move forward (as everything else will out of support by November except the LTSC of Redstone 1 (which we don't support now anyway))?

(From Wikipedia)

[azchohfi]

Our min right now is 16299 (1709).
Our target is 18362 (1903).

When we move to WinUI3, our min should align with whatever min WinUI3 supports since, AFAIK, there will be no reason to be any higher since WinUI3 will support everything down to that min. That is one of the advantages of WinUI3.

WinUI3's min version is 17134 (1803), so we'll need to bump our min anyway, but only to that. I'm not seeing the benefit of bumping our min to something higher than 1803. WinUI is only the UI layer, but a dev might need to target something lower to reach an audience that just didn't update windows (which does happen on Enterprises). By bumping our min to something higher that 1803, no dev would be able to have their min lower than than, since we would be saying that we don't support that. Why wouldn't why? I might just not be understanding the issue.

A different discussion is the lack of support for 1803. We should loop in some one from the WinUI team to understand what the out-of-support of 1803 means for WinUI3, since that will be their min.

[simeoncran]

FYI, Lottie-Windows requires 1809 in order to actually render a Lottie. LottieVisualSource will load on earlier versions but we can't render a Lottie, so AnimatedVisualPlayer will render its FallbackContent on Windows< 1809.

Therefore, moving up to 1809 will not change anything in Lottie-Windows behavior, and will be very welcome (because I always feel like we're disappointing customers who expect things to work < 1809).

@nishitha-burman

[vgromfeld]

Based on the support dates, 1803 is almost no longer supported. By the time the toolkit ship, it will probably no longer be supported at all.

Targeting 1809 for the min version seems to be a good choice for now, most of the users are there, it is compliant with WinUI3 min version and it targets an LTSC Windows build.
That seems to be a good start point 🏁.

We can also directly target 1903 but that would mean no longer supporting in the toolkit a Windows build which is still officially supported for ~10 months.

[michael-hawker]

@azchohfi this should be pretty straight-forward to implement, eh? The main thing is just if we want to go and clean-up all the conditional XAML and any other weird checks, eh?

I synced with @andrewleader on the notifications package. We'll leave the min down where it is excluded from this bump, but we'll make sure the target version aligns with the rest of the toolkit still so we can still get a single SDK requirement across the Toolkit and the Sample App needed for development.

[azchohfi]

Yes, literally just change it, and the TFMs for the nugets.

[Nirmal4G]

We can just target what WinUI 3/Project Reunion does!!

[azchohfi]

@Nirmal4G we absolutely can, on 8.x. This change is for 7.x.

[Nirmal4G]

So 7.x is not on top of WinUI 3?

[azchohfi]

No. 7.x is still on OS XAML UWP.

[marb2000]

Also, XAML Islands only works on 18362 (1903).