Windowscommunitytoolkit: Deprecate controls available in Fall Creators Update

[nmetulev]

Following Controls and APIs will be deprecated in 2.1:

• [x] HamburgerMenu
• [x] SlidableListItem
• [x] Paralax animation
• [x] RoundImageEx

[Vijay-Nirmal]

Fall Creators Update will be released on October 17 and v2.1 will be released on November 22. There is only one month gap. The update will take more than 3 months to reach all users. So if we remove these control in one month then many users won't have new controls(like NavigationView) and also the toolkit controls(like HamburgerMenu). My opinion is to do it for v2.2 instead of v2.1

There is no doc about RefreshContainer. I can find only one YouTube video. Maybe it won't be in Fall Creators Update. So we can't remove it in v2.1

[Odonno]

Right, the controls will be deprecated when FCU will be released but they should only be removed when FCU and the following version of W10 are released.

@Vijay-Nirmal Indeed, the RefreshContainer has no docs provided but it seems to be included in the Windows Insiders SDK (https://blogs.windows.com/buildingapps/2017/05/11/windows-10-sdk-preview-build-16190-released/).

[nmetulev]

@Vijay-Nirmal, agree with @Odonno, the controls will be marked deprecated, but won't be removed until a future release when it makes sense to release.

[Duranom]

Seeing as in consumer areas you can be two major updates behind with support, meaning after Fall creators people could in theory still be using Anniversary, will they be obsolete till the last oldest consumer supported version will be fall creators update and then removed?
And what for Enterprises? I think they can have long term service support up to 10 years, could they perhaps be moved to an obsolete package so you can benefit from the new things in the community toolkit but also use the very outdated in case you are supporting enterprises with older versioned?

[hermitdave]

I've added RoundImageEx to the list. @michael-hawker tested RoundedCorner on ImageEx XAML and that works for FCU

[nmetulev]

@Duranom, we will not remove the control until it makes sense for most developers. Even after the controls have been removed, the source code will continue to be available in our release notes.

[Vijay-Nirmal]

Since some computers in Anniversary Update are not eligible to upgrade to Creators Update. Microsoft decided to support those computers until 2023. Source: Microsoft cuts off Windows 10 support early for some PCs.

So Microsoft will support these devices until 2023 but UWPCommunityToolkit won't. That seems odd.

[Odonno]

@Vijay-Nirmal Well, it looks like a security focus, not a business focus. I am pretty sure Microsoft will stay with the 2 simultaneously maintened Windows 10 versions where 90% of users are.

[Vijay-Nirmal]

@Odonno Agree, but Windows 10 Security Update (Microsoft) will have support for those devices until 2023 but UWP Community Toolkit (Microsoft) won't.

Also, Microsoft drops support for Windows 10 November Update on 10-10-2017(Yesterday) but why do we remove November Update support before Windows 10 November Update support is dropped?

[Odonno]

@Vijay-Nirmal Well, it seems the support of these first Windows 10 versions (like Anniversary Update) have been expanded to additional months. But, in the Windows 10 Servicing Timeline, a Windows 10 major version should only be supported 1 year.

[Vijay-Nirmal]

@Odonno Microsoft will support each Windows 10 version for 18 months

Each Windows 10 feature release will be serviced and supported for 18 months. This is consistent with our current Windows 10 approach, but adds further clarity and predictability to organizations by aligning with Office 365 ProPlus.

Source: Windows and Office align feature release schedules to benefit customers

[Odonno]

@Vijay-Nirmal So, it should be 3 simultaneous Windows 10 version to support?

[Vijay-Nirmal]

@Odonno Right

[Vijay-Nirmal]

@nmetulev Why was PullToRefreshListView removed from the list?

[nmetulev]

I removed it after I realized that PullToRefresh is not in the latest FCU sdk. No point in deprecating it if there is no replacement

[Vijay-Nirmal]

@nmetulev Then, should the issues related to PullToRefresh be reopened?

[nmetulev]

Absolutely correct, will reopen them

[xied75]

Late to the discussion here.

1, From my observation, lots of code/control is in fact able to support earlier versions, because they are not calling anything newer in the SDKs.

2, Being a developer, I'll always try to NOT use fancy new APIs if old things also work. Why would I not want to support as wider the OS versions as possible?

3, May I suggest to Document everything that 'once' existed, the last version it supported, and where to find the code if one need to?

[nmetulev]

Hey @xied75, great points there.

On 1 and 2, we agree 100%. Deprecating control does not mean they will be removed from the toolkit immediately. They will remain in the toolkit but create a warning to let developers know that the controls will be removed in the future when it makes sense for most developers to have already moved to the platform controls.

On 3, great suggestion. The docs could still remain available once the controls have been removed, and contain info about where to get the source

[Vijay-Nirmal]

@nmetulev I think Principle #3 should be changed to (as per #1465#issuecomment-335795784 )

All features will be supported for three Windows SDK for Windows 10 release cycles or until another principle supersedes it.

[dotMorten]

@Vijay-Nirmal @nmetulev Why not support it for the duration of the OS version that is supported? (ie 10240 is no longer in support, and 10586 is soon out of support, so it would make sense to tie it to that support cycle)

[Vijay-Nirmal]

@dotMorten I am saying the same thing ("support for three Windows SDK"). Microsoft will support each Windows 10 version for 18 months. (Copy Paste of my above comment)

Each Windows 10 feature release will be serviced and supported for 18 months. This is consistent with our current Windows 10 approach, but adds further clarity and predictability to organizations by aligning with Office 365 ProPlus.

Source: Windows and Office align feature release schedules to benefit customers

Also, 10586 already ended support on 10-10-2017

[nmetulev]

We are currently supporting the same SDKs, and I don't expect that to change much in the future. :)

[Vijay-Nirmal]

Since Anniversary Update, x:Bind will implicitly convert bool to visibility. So BoolToVisibilityConverter should be deprecated.

Starting in Windows 10, version 1607, the XAML framework provides a built in Boolean to Visibility converter. The converter maps true to the Visible enumeration value and false to Collapsed so you can bind a Visibility property to a Boolean without creating a converter

[hermitdave]

Yes that is true however you can't force inverse behaviour and either need to use converter or raise two prop changed