5.0 Breaking changes

[nmetulev]

Issue to keep track of breaking changes planned for the 4.0 release (16299 min version rev)

• Remove obsolete controls (HamburgerMenu, SlidableListItem, etc)
• Move up min and max target
• Merge IWebView2 with IWebView (Support WebViewControl functionality for 17692 #2219)
• Remove twitter service obsolete properties (Twitter API - Complete implemenation of tweet JSON data #2266)
• Remove RoundImageEx

[michael-hawker]

Should we make a 5.0 one of these as well so we can keep track of things we know now will be useful to update when the min version reaches the current release point?

[grabinat]

Please do not remove SlidableListItem.
SwipeControl seems to be kind of buggy. There were several problems with it.
For example: If you scroll vertically through an Listview with an multitouch trackpad, swipes are executed for now reasons. This even happens in the XAML Controls Gallery app.
So for now, SwipeControl is not really an usable alternative for SlidableListItem.

[mdtauk]

You should also consider forward compatibility for future updates, and decide on how you will use Conditional Markup and the WindowsUI Library - going forward - to make things easier on you when adding or changing code in the future.

[nmetulev]

@grabinat, I understand your feedback and I encourage you to provide that feedback to the windows xaml team via the feedback hub. As a developer, you could still use the SlidableListItem by using the source, but we will be removing it from the nuget to ensure that only one control is supported and avoid fragmentation.

[nmetulev]

@mdtauk, I agree. With the Windows UI library providing backward compatibility to previous windows 10 updates, that should be a less of a problem.

[michael-hawker]

@nmetulev does this need to get updated/split now that we've had the version rev?

[mdtauk]

Another question to consider would be, does the UWP XAML Community Toolkit, take on a dependency of the Windows UI Library? So Microsoft.UI.Xaml as well as Windows.UI.Xaml?

[nmetulev]

I don't see why not if we need to. For example, the InfiniteCanvas uses the ColorPicker which doesn't work on Creators Update right now so taking a dependency on WinUI would enables us to fully support Creators Update for that controls.

[mdtauk]

I think it is safe to speculate that one day, the Windows UI Library may outpace OS versions for controls and XAML features. And it is a slim possibility that Windows may strip out the XAML controls completely so the UI Library is the only way to use XAML controls.

So as long as the future of the UI Library is secure, it probably makes sense as it will remain backwards compatible to the same N-2 versions of the OS, as the toolkit intends to be right?

[nmetulev]

If WinUI decides to move faster than that Windows SDK and update the controls more often, we can take a dependency on updated controls sooner while keeping the current backward compatibility (which is n-2)