Existing WindowsCommunityToolkit Repository Plans

[michael-hawker]

The Toolkit has grown a lot since its inception, both in terms of the amount of code and the number of folks using it. As we bring over components, we want to ensure they're working across our supported platforms, better documented, showcased with samples, well tested, and up-to-date with the latest modern Windows style guidance.

We're bringing over the most commonly used controls from the existing codebase, but this won't include everything even when we reach the stable vNext release. Future releases may include more with a mix of new and prior components. Some things are even in the platform now, so we want to work on better guidance on how to utilize built-in equivalents for prior Toolkit components.

So, for our existing WindowsCommunityToolkit repository, we're still trying to figure out if we overwrite the old code when we're ready (and shorten it back to be just Windows) OR do we archive it instead. We see pros and cons related to repo size, history, and discoverability with both approaches.

One of the main issues with the original repository is that it contains two forks, one for UWP + WinUI 2 and the other for Windows App SDK with WinUI 3. Build environment have changed underneath us, and we're not in a state where we're able to build our WinUI 3 branch here anymore. It means it's difficult to update and service the existing toolkit, except for UWP.

So do we start fresh and refer to the old repository when needed as a resource/archive OR do we try and maintain that history even if it won't be clean and be fairly large/bulky? What are your thoughts?

[Pdawg-bytes]

I'm a big advocate for archival. Most definitely archive the code and preserve it. Do not overwrite the repository. It may also be helpful for those in the future who want to build programs for older systems. I'd say move WinUI 3 development to a new repo and archive the old code 🙂

[heftymouse]

The commit history and tags will still be there for those who need it, in addition to the previous versions on NuGet.

[huynhsontung]

I'm also for archiving. The code change is so massive and not all the existing components will be ported over. Overwriting would mess up the history which makes it less useful and defeats the point anyway. It's better to start fresh.

[michael-hawker]

Yeah, if we 'overwrite' there'd still be a git log at that point, so you could jump back in time. But this is exactly the concern with such a massive amount of change and not everything going to be there initially (if ever for certain things already moved to the platform or not frequently used or with future plans for better alternatives)...

It seems more useful to have the archive be a lot more visible and findable and usable to compare against to bring things forward when needed. We can also use it to slowly transfer any issues over that remain problems for components that are brought over (we've already been moving feature requests/discussions to WCT Labs). We're trying to do a lot more rigid clean-up as we move things over and have been fixing some problems as we test things better and write more samples as well as making things work on multiple platforms.

[Pdawg-bytes]

I think keeping the actual code alive would still be better. I get that the git logs and stuff will be there but the code being there already is easier for those that want to look at the older code.

[bogdan-patraucean]

Considering that all the references now point to the old one and everyone searching will get results for the old one I'd still go with archiving.
The old one can point to the new and and vice-versa. References would be updated or deprecated going forwards, so considering the new project being named Windows, the WindowsCommunityToolkit could be renamed to WindowsOld.

[michael-hawker]

Yeah, GitHub can do some redirection here if we just rename the repository. In many places too we've used short links, so we can update those to point to the new repository. So, I'm not too worried about the logistical/linking side of things in either case. 🙂

[michael-hawker]

Last call for any additional feedback on this topic. Seems general consensus is to keep the original repo as an archive and move forward with this new one.

It has been refreshing to have a clean start, especially as we want to establish new guidance and procedures with how development starts in Windows Community Toolkit Labs. We do have more work to do in updating our wiki and documenting these steps though. We should try and start cleaning that up as we move towards the release.