search

CommunityToolkit / WindowsCommunityToolkit

The Windows Community Toolkit is a collection of helpers, extensions, and custom controls. It simplifies and demonstrates common developer tasks building .NET apps with UWP and the Windows App SDK / WinUI 3 for Windows 10 and Windows 11. The toolkit is part of the .NET Foundation.
https://docs.microsoft.com/windows/communitytoolkit/
Other
5.86k stars 1.37k forks source link

8.0 Release Plan 📝 #4488

Open michael-hawker opened 2 years ago

michael-hawker commented 2 years ago

Latest info on Pre-release blog here https://devblogs.microsoft.com/ifdef-windows/windows-community-toolkit-8-0-pre-release/

Read more about our whole 2022 Release Plan summary on the discussion here.

Before we start looking at our full 8.0 release, we're re-working our infrastructure for the toolkit. Read all about the new Toolkit Labs for Windows coming first here.

H1 2023 - 8.0 Release – Create/Rename Windows Community Toolkit Repo to CommunityToolkit/Windows

Details

We are currently maintaining two separate branches of the toolkit, one for UWP and one for WinUI 3/Windows App SDK. This has been done manually and isn't sustainable. We want to take our learnings on creating our new infrastructure with [Toolkit Labs for Windows]() and apply that to our existing code-base to streamline development of the Toolkit moving forward.

First, we would setup a CommunityToolkit/Windows repository that merges the project structure and updates to our processes from Toolkit Labs for Windows with our existing winui code branch. This would involve a lot of effort but also allow us to revitalize our samples and docs for specific features at the same time. It also makes it easier for a developer to focus on specific area within the Toolkit without having to load every Toolkit project or control.

Second, by moving to the new systems in CommunityToolkit/Windows, we would target all platforms within our single CommunityToolkit.WinUI.* based packages and namespaces for both UWP and WinUI 3.

This not only will help streamline our documentation and samples, but make it easier for developers to consume and multi-target XAML for UWP and WinUI 3 in their applications. Library developers can also do the same when building components on top of the Toolkit. We know migrating namespaces is a challenge, however, this incremental step makes migration between UWP and WinUI 3 easier for existing projects in the future as well.

Finally, we would rename or archive the existing CommunityToolkit/WindowsCommunityToolkit repo once the transition has been finalized. This repo would remain to preserve the history of our migration from UWP to a multi-targeted library. The new CommunityToolkit/Windows repo would be pruned to only preserve up-to the conversion from UWP to WinUI 3 (if possible).

Secondary Goals

In addition to the large goals of our releases above in re-working our infrastructure, other work on our samples and docs would need to be done as well. We would investigate if we could bring each Toolkit area over in chunks to re-work each area over time vs. trying to accomplish a giant move in one go. Hopefully this would also allow us to parallelize the work and engage any community members willing to aid in improving our samples and documentation for existing features.

Beyond infrastructure, there are new controls and components that have been worked on already or are already in development. The rest of this issue links out to existing known work that is being developed to track what needs to be migrated or incorporated into the plans above.

Issue Breakdown for 8.0 Release

Milestone Feature Board Bug Board Technical Board Sample Board

Below is a summary of the top level plan items. These items are in addition to everything that was initially released with the preview.

Legend of annotations:

Symbol Description
:hand: Help Wanted
:zero: priority 0 - must have for this release
:one: priority 1 - nice to have for this release
:two: priority 2 - stretch goal - unlikely for this release but we will try our best
:grey_exclamation: missing issue reference
:flashlight: investigating

Windows Community Toolkit Repo Refactor

These items will track what is required to initialize and setup the new infrastructure with the existing codebase.

Book-keeping

Refactors

New Features

Bugs

Migration Notes

Shomnipotence commented 2 years ago

Will it get a new icon?

michael-hawker commented 2 years ago

Will it get a new icon?

Possibly, there has been discussion on this topic in the past CommunityToolkit/WindowsCommunityToolkit#3182. As we get closer to setting a release date for 8.0, it's definitely something we should consider. Thanks for reminding us!

Nirmal4G commented 2 years ago

The namespace for Community Toolkit for Windows with CommunityToolkit.WinUI is too restrictive for what it enables or represents. I propose we move to CommunityToolkit.Windows!

I also have some ideas about repo structure that might not require heavy refactoring when and if we rebrand in the future.

robloo commented 2 years ago

I would like to add back DropShadowPanel and not deprecate it. The dev experience with this control is far superior to the new ideas in AttachedDropShadow which are just wrapping the implementation in composition (which is also poorly designed and doesn't fit in with XAML). AttachedCardShadow is slightly better but missing a lot of properties to control the look.

Arlodotexe commented 2 years ago

The namespace for Community Toolkit for Windows with CommunityToolkit.WinUI is too restrictive for what it enables or represents. I propose we move to CommunityToolkit.Windows!

Plans included supporting WinUI on other platforms, not just Windows, so using WinUI would be more appropriate.

Nirmal4G commented 2 years ago

Okay. But WinUI still represents Windows UI! Also, CommunityToolkit.WinUI.UI is more visually confusing at a glance. It's disturbing (to look at) to say the least.

May be CommunityToolkit.UI.Xaml would be a better alternative…?

Arlodotexe commented 2 years ago

We'll be using CommunityToolkit.WinUI in place of CommunityToolkit.Uwp.UI. When finished, there shouldn't be a CommunityToolkit.WinUI.UI namespace.

Nirmal4G commented 2 years ago

What about the non-UI WinRT namespace CommunityToolkit.Uwp? Seems farfetched to use WinUI here!!

michael-hawker commented 2 years ago

We'll be using CommunityToolkit.WinUI in place of CommunityToolkit.Uwp.UI. When finished, there shouldn't be a CommunityToolkit.WinUI.UI namespace.

There's still a base package without 'UI', but maybe it should just be WinAppSDK. I agree with @Nirmal4G that the current WinUI.UI is a confusing repetition, but we don't have a good solution for this at the moment mapped out. It is something we should figure out within our current naming scheme.

The main thing is that we want the UWP and WinUI packages to be closely aligned enough, but all using the same namespaces for this transition period.

Old Package New Package UWP New Package WinUI Notes
Microsoft.Toolkit CommunityToolkit.Common CommunityToolkit.Common Part of .NET Community Toolkit now, so centralized
Microsoft.Toolkit.Uwp CommunityToolkit.Uwp CommunityToolkit.WinAppSDK This is the problem package at the base
Microsoft.Toolkit.Uwp.UI CommunityToolkit.Uwp.UI CommunityToolkit.WinUI This is the current thing that sparked this conversation to avoid WinUI.UI
Microsoft.Toolkit.Uwp.UI.Controls CommunityToolkit.Uwp.UI.Controls CommunityToolkit.WinUI.Controls Here we can see where the benefits of the collapse would be

Communication the above and how we align namespaces across them would be very weird though, if we expand this table out...

Old Package Old Namespace New Package UWP New Package WinUI New Aligned Namespace
Microsoft.Toolkit Microsoft.Toolkit CommunityToolkit.Common CommunityToolkit.Common CommunityToolkit.Common
Microsoft.Toolkit.Uwp Microsoft.Toolkit.Uwp CommunityToolkit.Uwp CommunityToolkit.WinAppSDK CommunityToolkit.WinAppSDK????
Microsoft.Toolkit.Uwp.UI Microsoft.Toolkit.Uwp.UI CommunityToolkit.Uwp.UI CommunityToolkit.WinUI CommunityToolkit.WinUI
Microsoft.Toolkit.Uwp.UI.Controls Microsoft.Toolkit.Uwp.UI.Controls CommunityToolkit.Uwp.UI.Controls CommunityToolkit.WinUI.Controls CommunityToolkit.WinUI.Controls

It gets a bit messy trying to make it streamlined across both UWP and WinAppSDK/WinUI 3.

We also have things like the Connectivity package which needs to wedge between these as well...

robloo commented 2 years ago

Why not "CommunityToolkit.Uwp.UI" and "CommunityToolkit.Win.UI" for example. "Win.UI" makes sense but doesn't follow branding is the only issue I see.

michael-hawker commented 2 years ago

Why not "CommunityToolkit.Uwp.UI" and "CommunityToolkit.Win.UI" for example. "Win.UI" makes sense but doesn't follow branding is the only issue I see.

Yeah, I guess it's a matter of what we align to. We could go like CommunityToolkit.Windows.UI for instance. That may solve the conflicts. Though Windows is pretty broad (though we are the Windows Community Toolkit 😅). It's just that we know we're fairly aligned with building mostly on top of the WinUI platform, so we figured that alignment made more sense from the namespace/packaging perspective.

I mean going with Windows would make everything align nicely... 🤔

Old Package New Package UWP New Package WinUI Namespace
Microsoft.Toolkit CommunityToolkit.Common CommunityToolkit.Common CommunityToolkit.Common
Microsoft.Toolkit.Uwp CommunityToolkit.Uwp CommunityToolkit.Windows CommunityToolkit.Windows
Microsoft.Toolkit.Uwp.Connectivity CommunityToolkit.Uwp.Connectivity CommunityToolkit.Windows.Connectivity CommunityToolkit.Windows.Connectivity
Microsoft.Toolkit.Uwp.UI CommunityToolkit.Uwp.UI CommunityToolkit.Windows.UI CommunityToolkit.Windows.UI
Microsoft.Toolkit.Uwp.UI.Controls CommunityToolkit.Uwp.UI.Controls CommunityToolkit.Windows.UI.Controls CommunityToolkit.Windows.UI.Controls
robloo commented 2 years ago

@michael-hawker

I think Windows perfectly describes the platform the toolkit operates on. WinAppSDK is supposed to encompass a lot of different API's as well bringing them all together under one 'Platform'. WinUI is similar thinking I suppose.

That said, "Windows.UI.Xaml" for example with UWP was supposed to be the be-all-end-all platform as well and took the "Windows" term in a similar way. Look where we are today, so I understand the apprehension.

That said, I think your proposal is the best in terms of naming so far.

Arlodotexe commented 2 years ago

I'd have to again advocate for WinUI here. Using Windows may be nice and clean, but there are many different UI frameworks on Windows.

These specific CommunityToolkit packages have a direct dependency on WinUI 2 and WinUI 3, and none of the other ones.

Taking up the CommunityToolkit.Windows namespace steps on the toes of other frameworks that the CommunityToolkit may support in other packages by suggesting a single unified package that supports them all, which isn't our intent.

michael-hawker commented 2 years ago

I'd have to again advocate for WinUI here. Using Windows may be nice and clean, but there are many different UI frameworks on Windows.

Agree there are many forms of Windows app (thus my initial apprehension going in that direction); but that said, the "Windows App SDK" is the new branding for building Windows apps. And while we do depend on WinUI at the Uwp.UI layer, our current Uwp package and future Windows package would just depend on the Windows App SDK, as we may want to build more off of just that in the future.

I think this may align into a broader discussion of what being a "Windows app" means (FYI @shenchauhan). If documentation from Microsoft and the future the Windows App SDK is trying to bring is around those being the core definition of 'Windows Apps' then our use of 'Windows' in our package names could be justified.

If it encompasses other technologies, then that's more difficult, though easier to distinguish like our partnership with CommunityToolkit.Maui. If other groups want to join the Toolkit family, we could well have a more specific "CommunityToolkit.WPF, or something, in the future, if needed.

In all cases, we're still just defining CommunityToolkit.Windows to be anything built on the Windows App SDK (which is still a justifiable association), and that of course includes our WinUI 3 connection for the majority of our Toolkit work currently.

jeromelaban commented 2 years ago

I agree with @Arlodotexe here, using CommunityToolkit.WinUI seems to be clearer, and more specific to which framework it is targeting.

Yet, following the argument from https://github.com/CommunityToolkit/WindowsCommunityToolkit/issues/4488#issuecomment-1081063575, it should be CommunityToolkit.WinAppSDK.WinUI since there are WinAppSDK apis that are not WinUI specific, but are from a subset of WinAppSDK.

Arlodotexe commented 2 years ago

Yet, following the argument from #4488 (comment), it should be CommunityToolkit.WinAppSDK.WinUI since there are WinAppSDK apis that are not WinUI specific, but are from a subset of WinAppSDK.

Something like that would work for the package names on Nuget, though I think the discussion here is for the namespaces in the libraries, which will all be using the same namespaces as they're multi-targeting UWP, WinAppSDK and Uno.

We just need to agree on what the best choice of namespace is for something like this. The common denominator here without overstepping is WinUI, so that's what my suggestion is.

michael-hawker commented 2 years ago

We just need to agree on what the best choice of namespace is for something like this. The common denominator here without overstepping is WinUI, so that's what my suggestion is.

Yeah, that's the main concern is that we're still bridging this transition. And while CommunityToolkit.WinAppSDK.WinUI may be accurate for the new package (albeit verbose), it's even weirder to use as a namespace for existing UWP projects.

That's where both WinUI and Windows as roots here are more agreeable to being used in both UWP and WinAppSDK projects, are shorter, and not going to be confusing to one set of developers or the other.

Arlodotexe commented 2 years ago

That's where both WinUI and Windows as roots here are more agreeable to being used in both UWP and WinAppSDK projects, are shorter, and not going to be confusing to one set of developers or the other.

Agreed. My main concern is that the Community Toolkit will be very widely used. Windows encompasses more than just UWP and the WinAppSDK, which could cause confusion for Win32, WPF, MAUI, etc.

Also, these packages are now cross-platform thanks to Uno bringing WinUI everywhere, and not explicitly tied to Windows anymore.

Arlodotexe commented 2 years ago

Perhaps a good middle ground would be

Though I haven't seen a library that references only the Windows SDK without going through UWP or the WinAppSDK, though. These are both tied to their respective WinUI libraries 🤔

michael-hawker commented 2 years ago

Another thing to consider is that we've already shipped CommunityToolkit.WinUI.* and CommunityToolkit.WinUI.UI versions of these packages for our existing WindowsAppSDK/WinUI 3 support, so if we change the pattern for 8.0, it'll be another breaking change for them (though part of the point of 8.0 is to break this to align for the future, so it's OK to do, but just want to be conscious that we'll have another break).

Nirmal4G commented 2 years ago

@Arlodotexe @jeromelaban

With Windows' current position among Devs, there'll be many more WinUIs and WinAppSDKs come and go but the one thing that'll never change (for the time being) is Windows. Even if you're targeting via Uno, you're still using Windows.* namespaces than Uno.*. Apart from all the internal transliteration that Uno provides, on the surface it's still using Windows API surface.

Hence, IMHO, for all the packages that targets Windows SDK and its derivatives, we can and should go with CommunityToolkit.Windows.* as mentioned here by @michael-hawker. I've been telling this from v7 of the toolkit. Now might be the right time to unify this once and for all and leave it as such for all future releases.

Also, if it were me, I would go with Community.Toolkit or Community.Extensions (just for .NET packages; similar to Microsoft.Extensions). There is also Community.Appkit would apply to App-oriented projects than the generic Community.Toolkit/Extensions would apply to all .NET projects.

Also, having Community.* as a root for all projects that are either related or an extension to projects by M$FT but are maintained by employees or people outside M$FT would be beneficial. This could give Community.* packages an official boost by .NET Foundation and could have a verified tag in the NuGet repository.

VisualStudio is already using Community.* root. See Visual Studio Community Toolkit.

Finally, my advice is the same from the Framework Design Guidelines―Use simple words or existing terminologies to state the intent or purpose of your class identifiers, namespace or assembly names. Make your Root namespaces concise, clear and common.

michael-hawker commented 2 years ago

@Nirmal4G the VS extensions may have chosen to use Community, but there are a few other pre-existing projects that are using Community as a root; so they/we can't take ownership of that to get the 'checkmark' on NuGet. That's why we chose CommunityToolkit as a root to associate directly with our GitHub organization and the .NET Foundation, as you call out as important.

Appreciate your input on the Windows moniker. Definitely need to get some broader input from even more folks on their preferences for us to make a decision here it seems.

Arlodotexe commented 2 years ago

With Windows' current position among Devs, there'll be many more WinUIs and WinAppSDKs come and go

Important to note that this distinction is missing a key point - we're writing WinUI code here. It works under WinAppSDK, UWP and other platforms via Uno, but we're writing code that uses WinUI exclusively.

the one thing that'll never change (for the time being) is Windows

Windows apps can be developed with many other UI frameworks that aren't WinUI. There may one day be toolkits for those (we already have a Maui Community Toolkit), so we need to be mindful of them and not take a namespace which may imply a single package that supports both WinUI and Maui.

Nirmal4G commented 2 years ago

@michael-hawker

NuGet has a concept of multiple owners per root and different owners per sub root. The Community is WE and we are not one person or organization. NuGet could reserve the certain roots like Community and the roots that starts with username as .NET Community or something along the lines.

This is a special case than roots like Microsoft or Windows. You can do the ownership on Community.Toolkit as the root. As I remember, previously we had Microsoft.Toolkit as the root. So, we are only changing from Microsoft to Community. Thus, the change is familiar and understandable.

@Arlodotexe

The word WinUI is just a short form of Windows UI. So, It doesn't make much of a difference. The word WinAppSDK is just a horrible name to put it in namespace or assembly name. However, it could work as a product name.

Let me once again quote myself here:

Finally, my advice is the same from the Framework Design Guidelines―Use simple words or existing terminologies to state the intent or purpose of your class identifiers, namespace or assembly names. Make your Root namespaces concise, clear and common.

MAUI is a different product and we're not using the word MAUI anywhere. So, we're safe here.

michael-hawker commented 2 years ago

@Nirmal4G we can't claim a NuGet sub-root unless we own the root. So, we can't own the root of Community if many different other folks are already using it, as is the case here. That's why we went with CommunityToolkit as it's something specific we could own as a root and delegate sub-roots out as we work with different communities like the MAUI folks.

With Microsoft.Toolkit, Microsoft was still the root. We didn't own either Microsoft or Microsoft.Toolkit as roots we could control. That's why we wanted/needed to create our own root to have greater control over how we could manage our packages on NuGet.

Arlodotexe commented 2 years ago

@Nirmal4G

The word WinUI is just a short form of Windows UI. So, It doesn't make much of a difference.

WinUI is a product name, the name of the UI framework we're using in this repo. It matters when looking for the nuget package that is compatible with the UI framework in your app.

The word WinAppSDK is just a horrible name to put it in namespace or assembly name. However, it could work as a product name.

Agreed. We won't be using WinAppSDK in the namespace, we'll have a single unified CommunityToolkit.WinUI namespace for both WinUI 2 and WinUI 3, which will work under UWP and WinAppSDK respectively.

Nirmal4G commented 2 years ago

@michael-hawker @Arlodotexe

Guess it's a limitation of NuGet. Can't be helped then!

Hmmm... Still don't like the separation between CommunityToolkit.WinUI and CommunityToolkit.Uwp or whatever it ends up. That's why I liked the single Community.Toolkit.Windows namespace.

BTW, the assembly/package names can be different. We can use UWP or WinRT and WinUI moniker on Package and Assembly name while keeping the namespace sane.

With that in mind, I propose we use Community.Toolkit.* for namespace while CommunityToolkit.* for the assembly/package names.

michael-hawker commented 2 years ago

To clarify, the current thinking/plan will be that we'll have a singular namespace, e.g. CommunityToolkit.WinUI.* (or whatever) but two sets of packages under: CommunityToolkit.UWP.* for UWP and CommunityToolkit.WinUI.* for WinUI 3.

This would help with interop and migration of moving from UWP to WinUI 3 as the namespaces will be aligned, and allows us the opportunity to merge with Uno in the future and support Uno + UWP and Uno + WinUI 3 via the independent packages. Unfortunately we can't have a single package support all combinations.

I think since we're the CommunityToolkit organization keeping the root namespace as CommunityToolkit would still make sense though as the first part of a namespace is typically the organization name.

Nirmal4G commented 2 years ago

@michael-hawker

The WinUI can be for UI APIs but what about the non-UI APIs? Will they use the existing UWP or older WinRT or something else?

I recommend using Windows in the namespace as you proposed previously as it unifies nicely. But we can use different moniker on assembly/package names.

I do agree that CommunityToolkit is more of a vendor name in the namespace. Having to separate the words gives you more freedom to have a certain areas of code to be put under different namespace with the Community domain.

Let's say, may be in future, you want a separate namespace for experimental code or a work-in-progress extension for a existing feature, you can put those under Community.Preview.* or Community.Extensions.* before moving those into Community.Toolkit. Even Windows APIs follow a pattern like this.

IMO, Even CommunityToolkit is too generic. So, it doesn't matter if we separate those words at the namespace level. It only gives more room for code that can't be put under Toolkit. We can still keep the CommunityToolkit name everywhere else except in namespace.

Arlodotexe commented 2 years ago

The WinUI can be for UI APIs but what about the non-UI APIs? Will they use the existing UWP or older WinRT or something else?

I'll re-post this from above for consideration:

Perhaps a good middle ground would be

Though I haven't seen a library that references the Windows SDK without going through UWP or the WinAppSDK, though. These are both tied to their respective WinUI libraries 🤔

AbdAlghaniAlbiek commented 2 years ago

Hey @michael-hawker In the list of new features, I remember you put my issue CommunityToolkit/WindowsCommunityToolkit#4401 beside StackedInfoBar behaviour under "introduce big changes" mark.. Are you forget something or it's error from github because this issue/PR CommunityToolkit/WindowsCommunityToolkit#4338 has mentioned twice !?

michael-hawker commented 2 years ago

Hey @michael-hawker In the list of new features, I remember you put my issue CommunityToolkit/WindowsCommunityToolkit#4401 beside StackedInfoBar behaviour under "introduce big changes" mark.. Are you forget something or it's error from github because this issue/PR CommunityToolkit/WindowsCommunityToolkit#4338 has mentioned twice !?

Yup, just a copy/paste issue, I've fixed the link to the PR above. We've been pretty focused on getting CommunityToolkit/WindowsCommunityToolkit#4487 ready to go. Once that's up, we'll move some of the current PR/features over there to continue their development/feedback before we restructure the current repo here for 8.0 on top of the new infrastructure.

GurliGebis commented 1 year ago

Is it safe to assume this has been cancelled and the project is dead? This repo has been dead since October.

michael-hawker commented 1 year ago

@GurliGebis these types of comments are never constructive to OSS repos. Instead, would you like to help us work on something together? Try out and provide feedback on one of our new controls perhaps?

First, the header in the description labels this milestone for H1 2023, which is the first half of 2023.

It also elaborates that there's a lot of work to do. As mentioned in this issue:

We want to take our learnings on creating our new infrastructure with Toolkit Labs for Windows and apply that to our existing code-base to streamline development of the Toolkit moving forward.

We have been doing all our investments on infrastructure on our Labs repo here here. From there we will migrate code here into a new format on top of the new infrastructure and either replicate back onto this repo or redirect depending on how much changes and how much history we can/want to maintain from existing components.

GurliGebis commented 1 year ago

@michael-hawker sorry if I worded it badly, that wasn't my intention. It was more of a wondering if it was safe to use for new projects, since it seemed dead (hadn't noticed the Labs repo) It is great to hear it is still alive 😃♥️

niels9001 commented 1 year ago

@michael-hawker sorry if I worded it badly, that wasn't my intention. It was more of a wondering if it was safe to use for new projects, since it seemed dead (hadn't noticed the Labs repo) It is great to hear it is still alive 😃♥️

Here are the check-in components in Labs (https://github.com/CommunityToolkit/Labs-Windows/tree/main/components).. some of those will be coming to the new version of the Toolkit 😊.

And some more that are in PR: https://github.com/CommunityToolkit/Labs-Windows/pulls

michael-hawker commented 1 year ago

Discussed more about the namespace concerns moving forward. 8.0 is going to be a primarily control focused release as we move to our new infrastructure. For now, we've settled on using the root of CommunityToolkit.WinUI.

Old Package New Package UWP New Package WinUI Namespace
Microsoft.Toolkit.Uwp TBD TBD (same?) TBD
Microsoft.Toolkit.Uwp.UI CommunityToolkit.Uwp CommunityToolkit.WinUI CommunityToolkit.WinUI
Microsoft.Toolkit.Uwp.UI.Controls CommunityToolkit.Uwp.Controls CommunityToolkit.WinUI.Controls CommunityToolkit.WinUI.Controls

For the base UWP helpers we envision something that helps with APIs across Windows based TFMS like UWP, WindowsAppSDK, the general net6.0-windows, etc... e.g. should be useable by WindowsAppSDK and UWP developers, maybe even WPF as well. This will probably be investigated more as part of a future release. In this case using something like CommunityToolkit.Windows or CommunityToolkit.WinRT as a base namespace/package id would be investigated. For now that decision will be postponed.

GreenShadeZhang commented 1 year ago

It's great to hear that an update to Toolkit Labs for Windows is underway and hopefully it will be available earlier this year.

SeRgI1982 commented 1 year ago

We have June 2023 and 8.0 Release is not even in the middle.

I have noticed that some PR's waiting for review over the year.

@michael-hawker, how can we help ?

kmgallahan commented 1 year ago

@SeRgI1982

The Windows Community Toolkit 2023 Update

2023 Windows Community Toolkit Feedback

WCT 8.0 Pulse showing progress

WCT 8.0 Repo

Other WCT 8.0 points of discussion

michael-hawker commented 1 year ago

Pre-release blog up the other day: https://devblogs.microsoft.com/ifdef-windows/windows-community-toolkit-8-0-pre-release/

Last couple of days to report issues before we build final release, report anything at new repository here: https://github.com/CommunityToolkit/Windows