8.0 Release Plan 📝 #4488
Comments
|
Will it get a new icon? |
Possibly, there has been discussion on this topic in the past #3182. As we get closer to setting a release date for 8.0, it's definitely something we should consider. Thanks for reminding us! |
|
The namespace for Community Toolkit for Windows with I also have some ideas about repo structure that might not require heavy refactoring when and if we rebrand in the future. |
|
I would like to add back |
Plans included supporting WinUI on other platforms, not just Windows, so using |
|
Okay. But WinUI still represents Windows UI! Also, May be |
|
We'll be using |
|
What about the non-UI WinRT namespace |
There's still a base package without 'UI', but maybe it should just be 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.
Communication the above and how we align namespaces across them would be very weird though, if we expand this table out...
It gets a bit messy trying to make it streamlined across both UWP and WinAppSDK/WinUI 3. We also have things like the |
|
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 I mean going with
|
|
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. |
|
I'd have to again advocate for
These specific CommunityToolkit packages have a direct dependency on WinUI 2 and WinUI 3, and none of the other ones. Taking up the |
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 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 In all cases, we're still just defining |
|
I agree with @Arlodotexe here, using Yet, following the argument from #4488 (comment), it should be |
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. |
Yeah, that's the main concern is that we're still bridging this transition. And while That's where both |
Agreed. My main concern is that the Community Toolkit will be very widely used. Also, these packages are now cross-platform thanks to Uno bringing WinUI everywhere, and not explicitly tied to Windows anymore. |
|
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 🤔 |
|
Another thing to consider is that we've already shipped |
|
@Nirmal4G the VS extensions may have chosen to use Appreciate your input on the |
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.
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. |
|
NuGet has a concept of multiple owners per root and different owners per sub root. The This is a special case than roots like The word Let me once again quote myself here:
MAUI is a different product and we're not using the word MAUI anywhere. So, we're safe here. |
|
@Nirmal4G we can't claim a NuGet sub-root unless we own the root. So, we can't own the root of With |
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.
Agreed. We won't be using WinAppSDK in the namespace, we'll have a single unified |
|
Guess it's a limitation of NuGet. Can't be helped then! Hmmm... Still don't like the separation between 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 |
|
To clarify, the current thinking/plan will be that we'll have a singular namespace, e.g. 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 |
|
The I recommend using I do agree that 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 IMO, Even |
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 🤔 |
|
Hey @michael-hawker |
Yup, just a copy/paste issue, I've fixed the link to the PR above. We've been pretty focused on getting #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. |
|
Is it safe to assume this has been cancelled and the project is dead? |
|
@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 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. |
|
@michael-hawker sorry if I worded it badly, that wasn't my intention. |
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 |
|
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
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 |
|
It's great to hear that an update to Toolkit Labs for Windows is underway and hopefully it will be available earlier this year. |
|
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 ? |
|
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 |
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/WindowsCommunityToolkit.WinUI.*winuibranch.CommunityToolkit/WindowsCommunityToolkitrepo when migration is completed.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/Windowsrepository that merges the project structure and updates to our processes from Toolkit Labs for Windows with our existingwinuicode 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 singleCommunityToolkit.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/WindowsCommunityToolkitrepo 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 newCommunityToolkit/Windowsrepo 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:
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
The text was updated successfully, but these errors were encountered: