I've seen a few times examples where things are fixed in WinUI 2.x/Windows yet the issue occurs again in WinUI 3.x or vice-versa. Managing two code bases with changes that need to apply to both is extremely difficult to do manually. How is Microsoft managing this? My concern is if some automated tools/checks aren't in place we are going to have lots of mismatches in code for the next 1+ year as WinUI 2.x and WinUI 3.x are supported simultaneously. This is going to be very frustrating and time-consumer for developers in the edge cases.
Examples:
I'm sure there are several more cases.
I'd hope they'd have a converter that takes the code, find and replace the name spaces and put them in WinUI 3.
@robloo we are doing a semi automated merge from WinUI2 (at certain points like stable release or pre-release commits) to WinUI3 branch before each WinUI3 preview. Both trains are moving so there is going to be some delay between a fix going into Winui2 and it showing up in WinUI3 (in the next preview).
@anawishnoff @MikeHillberg I think that we should add this to our preview documentation. Knowing which version of winui2 is present in the preview will set expectations and allow users to identify actual bugs opposed to features which were missing from the winui 2 version we merged.
@StephenLPeters Definitely agree that we should mention which version is using what, but when you say:
Knowing which version of winui3 is present in the preview
Do you mean which version of WinUI 3 is present in WinUI 2 previews? Or which version of WinUI 2.x in present in the current WinUI 3 preview?
I believe that for preview 1, we didn't have 2.4 support and we mentioned that in the known issues section of the release notes. For preview 2, we have parity with 2.4 but I can also add a note to the release notes doc that mentions the exact version that WinUI 3 Preview 2 uses.
updated my comment, I meant which winui 2.x version is in the winui3 preview.
Glad to hear this is somewhat automated.
I'm assuming WinUI 3.x is considered the main code and all WinUI 2.x changes by the community are fed into it before a major release (in an automated way). WinUI 3.x changes useful for WinUI 2.x are then cherry picked manually as they are needed.
If so, adding the version of WinUI 2.x pulled in for each WinUI 3.x release should be enough going forward.
I'm going to close this as the version of WinUI 2.x used for the WinUI 3.0 preview is added (pictured below). I'm also glad there is a somewhat 'automated' method of syncing changes -- although I suspect it's not perfect like all things. Regardless, I can't think of any benefit keeping this issue open.
Most helpful comment
@robloo we are doing a semi automated merge from WinUI2 (at certain points like stable release or pre-release commits) to WinUI3 branch before each WinUI3 preview. Both trains are moving so there is going to be some delay between a fix going into Winui2 and it showing up in WinUI3 (in the next preview).