Template10: DISCUSSION: backwards compatibility

[JerryNixon]

There are many things to support here:

1. What version of Visual Studio
2. What version of NET Standard
3. What version of XAML
4. What version of UWP

UWP

Here's what we have:

1. 07/2015 UWP 10240 TH1 Launch
2. 11/2015 UWP 10586 TH2 November Update
3. 03/2016 UWP 14393 RS1 Anniversary Update
4. 04/2017 UWP 15063 RS2 Creators Update
5. 10/2017 UWP 16257 RS3 Fall Creators Update

Our goal should be support the largest install base while limiting the surface area needed to test for Template 10. My recommendation is that we create a range, in this case, three. This would mean we support the most current UWP and two before it. And, it means when another is released we would support that with the two before it, dropping older. This aligns nicely to our internal telemetry for what versions of Windows are most-installed in the wild.

For now:

Visual Studio

We have to consider SKU of Visual Studio. For this, I think supporting Community, Professional, and Enterprise is easy and makes plenty of sense. We will always support all three.

We also have to consider the version of Visual Studio. Right now we support Visual Studio 2017, but we do not support Visual Studio 2015. My goal is to always support only one version. This was a big deal because the VSIX structure changed between 2015 and 2017; the work necessary to support both was unnecessarily arduous, especially for an open source project like this.

XAML

This only has to do with our controls, not the framework. Still. I hate that XAML is not backwards compatible. The good news is that XAML in RS3 is incompatible with RS2 and RS1, but it introduces a mechanism to keep it from breaking in the future. That is to say, it is becoming backwards compatible.

Hamburger Menu

I want to deprecate the Hamburger Menu immediately, never bringing it across to Template 10.2. I want to extend the new NavigationView in RS3 as NavigationViewEx and let it serve Template 10.2. But, that means we no longer would support Anniversary or Creators Update.

So, what to do.

I think we need to ship both. For now, even though I do not want to, I think we need to ship the Template 10 HamburgerMenu and NavigationVIewEx with Template 10.2. How to make this clean? I can easily write the NavigationViewEx as a separate Nuget package. So I will. I am trying to separate the HamburgerMenu, but it is full of dependencies, which might get worked out here soon.

This make sense?

NET Standard

As you may know the RS3 SDK will ship a NET Standard 2 UWP. That is brilliant. What does it mean for backwards compatibility? The truth is, it means if Template 10.2 jumps to NET Standard 2 it will no longer support Anniversary or Creators Update. Well, dang it.

Here's what I suggest. The new API in NET Standard 2 are not important to Template 10.2 yet. So, there is no compelling reason to upgrade it to NET Standard 2 right now. Next spring, when RS4 is released, we might find a reason to upgrade. Here's hoping there is no NET Standard 2 requirement in NavigationView. Right now there is not. Not telling what that would mean.

What do we do if NET Standard 2 is a requirement? What do we do if we cannot decouple the Hamburger Menu? The goal will be to support 3 versions of UWP. So, there are still some unknown.

Windows Phone

Okay, quick note here. As long as Windows Phone falls in our UWP range, we will support it. Listen, I carry a Windows Phone and so does everyone else in my family. But, I am not going to bend over backwards building support in T10 for a halted operating system. I am likely going to Android myself, to be honest, but I will hold onto my 950 as long as I possibly can.

Feedback

I want to point out that is might sound like I have made a lot of decisions for Template 10 in this post. I want you to know that these are the "default" directions we are going. There is always time to coerce me with a good point, so please feel free and welcome to make suggestions or comments.

[rpedretti]

UWP

I agree. I myself have a Project here testing some techniques to import Resources dictionaries based on api level and if classes exists, like AcrylicBrush.

So 3 versions to me is good.

But i have some question regarding Windows 10 S.

• T10 supports Windows 10 S?
• Will Windows 10 S keep up with the "regular" Windows updates?

Visual Studio

Since the version of Visual Studio is not bound to the OS version it's fine to me to support the latest only. In the future there might be features T10 will need that only certain version of Visual Studio will have, like support to NetCore 2.0

XAML

It's hard to keep backwards compatibility if the tool itself won't. But Visual Studio already warn you if you try to use something that's not presente at target minimum version, again, like the AcrylicBrush. I don't know how the framweork handles styles like the ListView with the RevealStyle where it's not presente in current release of Windows, at least not for devs outside MS

Hamburguer Menu

The Windows Template Studio already have one template for hambúrguer menu that uses the Micorsoft.Toolkit.Uwp. Maybe we should drop support and let them do it. I know using two tool for this might suck a little but it's not hard to put T10 on top of that template.

NET Standard

No idea :)

Windows Phone

I still like my 640 but i follow the same line as you, by the time I feel the need to change I'll get na Android. My hopes on mobile is that MS will presente us that 'new class of device' they are promising. When this happen we should talk about that and hope that everything still Works on CShell!

[JerryNixon]

Windows 10 S

Let me answer the Windows 10 S questions since I know the answer. Imagine if you took Windows 10 home edition and removed the ability to install Win32 apps (except through Centennial). That is Windows 10 S. It is another SKU of Windows 10 with that one (at least) characteristic. What do we need to do for Template 10 to support Windows 10 S? Nothing. It's UWP all the way. Should be called Windows 10 UWP!

[mdtauk]

UWP

I think supporting a build that works on the November Update makes sense, as it is still relevant to the Current Branch for Business, and Long Term Servicing Branches. But it should only be maintenance, with ongoing work only going back to Creators, and Fall Creators Updates. In future, Windows 10 N and N-1 probably makes the most sense.

Visual Studio

On-going work on the latest version of Visual Studio, with maintained older version of the VSIX going back 1 version of VS

XAML

In the future, conditional XAML will solve this problem, and as it is mostly the Acrylic Brush support that is the sticking point, either add a simple Acrylic control to give Creator's Update users a way to implement it manually(there are code samples out there to do it) and just focus on FCU onwards.

Hamburger Menu

The control you made as is, still exists in previous versions of Template 10. For v2.0 extend the native control, and leave the older versions in its own branch if users want to grab it from source or an older VSIX.

.NET Standard

Keep on the older version until there is a specific feature you need, in a future release of Template10

Windows Phone

Thanks to Zac Bowden, we know what Microsoft plans to do with Windows Phone, and it is on Life Support with minimal backporting of APIs and features. So apart from ensuring support for small windows/small form factors, any Phone specific elements like StatusBar styling, etc can be an optional thing.

[callummoffat]

I don't believe that supporting 1511 makes sense. LTSB doesn't support UWP AFAIK.

[jp-weber]

UWP

I think supporting the builds with the highest distribution would be make sense. Aduplex make good market share about the OS versions. Make it sense if we say that we support at least 85 percent?

Visual Studio

I think with larger and smaller changes like C#7 support, it makes sense to support only the newest version.

Windows Phone

Windows Phone is a big question mark. According to Windows Central the feature2 update backport the new RS3 and RS4 API. The question is, how much work is necessary to support W10M and how many customers use W10M?

The communication from Microsoft is very poor. I have no idea, what they think? That we developer would be happy if we have uncertainty about months? And we still support this OS where the customers left the platform out of uncertainty?

[callummoffat]

Windows 10 Mobile, I think, isn’t so much a question mark as a big crossing out. Given Microsoft’s total radio silence on the matter, the lack of features in FEATURE2 builds coupled with the conspicuous lack of most of the new RS3 features that you’d think would come as part of OneCore, it is fairly safe to assume at this stage that Mobile has gone the way of the dodo.

Even if this is not the case, it seems borderline idiotic to make the effort to support a platform with no obvious interest from OEMs (or even the OS developer), a minimal userbase and seemingly no market value.

Sent from Mail for Windows 10

From: revan1199
Sent: Friday, August 11, 2017 8:41 PM
To: Windows-XAML/Template10
Cc: Callum Moffat; Comment
Subject: Re: [Windows-XAML/Template10] DISCUSSION: backwards compatibility(#1521)

UWP
I think supporting the builds with the highest distribution would be make sense. Aduplex make good market share about the OS versions. Make it sense if we say that we support at least 85 percent?

Visual Studio
I think with larger and smaller changes like C#7 support, it makes sense to support only the newest version.
Windows Phone
Windows Phone is a big question mark. According to Windows Central the feature2 update backport the new RS3 and RS4 API. The question is, how much work is necessary to support W10M and how many customers use W10M?
The communication from Microsoft is very poor. I have no idea, what they think? That we developer would be happy if we have uncertainty about months? And we still support this OS where the customers left the platform out of uncertainty?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[JerryNixon]

The AdDuplex numbers are close enough to the real telemetry that we can use them.

[callummoffat]

I think this backwards compatibility issue needs to be resolved before we release 10.2. Personally, I'm of the opinion that maintaining backwards compatibility with <1607 isn't essential.

The AdDuplex numbers show that Windows 10 releases prior to the Anniversary Update have pretty minimal market share. Supporting these versions seems counterproductive, as it would hold back our ability to evolve Template 10 for little or no reason.

Given the somewhat glacial rate at which enterprises adopt a new operating system, I suspect the adoption of Win10 in the enterprise is still very much in it's infancy - therefore, we have a window rn to drop support for these older versions before businesses begin mass adoption of Windows 10 and UWP (at which point we will need to rethink our stance to compatibility).

So, I think we should drop 1507 and 1511, and perhaps revisit backwards compatibility in a few months, maybe a year, to discuss how we handle it in future?