Poll: How Backwards-Compatible should Template 10 be?

[JerryNixon]

Hey @Windows-XAML/contributors

I want your opinions. You are never shy to provide them. :)

Right now, Template 10 supports 10240 and 10586, and when Redstone is released, we will support that, too. My question is, when we do, should we continue supporting 10240? What about 10586?

This is an important question because there are several non-compatible XAML changes coming Redstone that could help us accomplish a lot of things in Template 10. They are not critical, or necessary at this time, but they certainly have me thinking about backwards-compat now that some of the platform is incompatible.

Thoughts?

[callummoffat]

I think T10 should always support the two most recent feature updates to Windows 10. So, we drop 10240 support when RS1 comes out, but keep 10586 support. Then, when RS2 comes out, we drop support for 10586. That should ensure that T10 supports the vast majority of devices. My opinion is that CB builds more than two cycles old are just dead weight - people who are still on 10240, for example, are people who probably won't be prolific app installers.

That's my opinion.

[mvermef]

I can't imagine there are that many devices with 10240 left installed especially since Update unless it is not set to automatic (user intervention). I agree drop 10240 when RS1 is released, it's dead weight in the code base.

[darenm]

While I like the idea of supporting current + 1 prior, I'd hate for the framework to miss out on (hypothetical) features that RS1 might bring. We can handle (poorly, IMHO) API variations in code, but we cannot in XAML. Does it make more sense to consider a Threshold variant and a Redstone variant? Threshold would support 10586 but is in maintenance mode, whereas Redstone branches and supports new capabilities.

[callummoffat]

What about this? We do two packages (say, Template 10 and Template 10 LTS). One always supports the latest branch of feature updates (RS1, RS2), and gets actively maintained with new features and enhancements. The other supports the previous branch (TH1, TH2), and gets maintenance support only.

I think this would work pretty well. If I were Microsoft, I would stick to introducing breaking changes on the first release of a cycle only (i.e. RS1).

[JerryNixon]

Since we're all brainstorming, I'd like to share my vision for Template 10 and how it could apply to this. Image a stand-alone NuGet package called something like Template10-Core that included WindowWrapper, DispatcherWrapper, and NavigationService. This lightweight assembly could be included in many apps, including those who are not interested the UI controls. Now imagine another NuGet package called Template10-Controls that included HamburgerMenu, and the other controls we love. This package would have a dependency on Template10-Core. Because the non-backwards-compat tech is mostly XAML, we could potentially introduce Template10-Control-10240, Template10-Control-10586, Template10-Control-Redstone, and so on. We just branch with every version and maintenance continues only on the current branch. This is just an idea. I'd still love to hear from more of you about what you think we should do.

[callummoffat]

I like the idea of separating the library into different Nuget packages. MvvmLight does this, and it works really well. That would allow for excellent backwards compatibility. However, you would need to consider: what packages would the template pack use?

[MichaelPetrinolis]

I really like the idea of splitting the library. If we could also share code and interfaces in core with xamarin forms, it would be perfect. In my opinion, if Navigation service , messaging , a dialog service and related interfaces are common between platforms, most business services and viewmodels logic could be shared among them.

[sebfrie]

I like the idea of branching, too. It would be a shame if we always missed out on the latest (XAML) features.

[alexdresko]

Can the functionality split happen in such a way that integrating with another library such as MVVM Light can be made to to eliminate conflicting/duplicate functionality between the libraries? I.E., multiple navigation services, multiple means of checking for design mode, etc... Just curious. I can't imagine how that might happen, but I think that would eliminate a lot of confusion if it were possible.

[Dinchy87]

i have a uwp app that has 200-600 download each day and i still see a lot of 10240 users so it would be good that Template10 is still supported. Maybe with the release of Redstone/anniversary this will change and users will update to it.

[callummoffat]

@alexdresko, I believe that one of T10's goals is to make using MVVM easier, without integrating a framework. Even though MVVM is basically the best way to do XAML, some people don't use it, and T10 reflects that.

[callummoffat]

I tend to agree. There are 10240 users for my app as well (although I don't get as many downloads as you), but I suspect many of these are business users, and not consumers. Business users make up the majority of people who have a good reason to defer updates.

[Opiumtm]

I think Template10 should support actual versions on desktop and mobile. On mobile devices are often updated to latest version, but on desktop there is a completely different story. So, to be truly coherent, we should periodically analyze major version distribution statistics. Only real live data can show what OS versions are actual.

[MikeBishop]

I'll pile on the branching option, as well. Remember that there are effectively four populations at any time: Active Branch / Insiders (currently RS1, will be RS2 once RS1 ships), Current Branch (currently TH2, will be RS1), Current Branch for Business (currently TH1, will be TH2), and Long-Term Servicing Branch (currently TH1; TH1 remains supported for 10 years).

Ten years is a long time, and we surely don't want to be shackled to TH1 compatibility for a decade. Granted, LTSB users don't have the Store IIRC, but there will still be sideloaded apps. There needs to be a way to maintain those apps easily.

I think T10 should probably branch each time Windows declares a new LTSB -- the current build supports the most recent LTSB and forward; if you need to build for something older, you get the latest from the fork that supports your oldest targeted LTSB. At that point, if you want to make breaking changes that require the most recent LTSB or newer, the current is free to do so.

[JerryNixon]

Thanks everyone for your feedback, I am locking this conversation.