Versioning strategy for UI packages

[rockfordlhotka]

I'd like to have a discussion about something that's becoming a bigger problem as time goes on: UI frameworks are no longer necessarily coupled to .NET releases.

For example, MAUI 8 is going out of support in May 2025, long before .NET 8 goes out of support.

Although we're working toward the CSLA 9 release right now, I expect CSLA 8 will be in use - and still get patches - until .NET 10 comes out and makes .NET 8 go away.

That means there's a gap from May-November (probably) during which CSLA 8 releases will not be able to include MAUI packages.

What I've been doing for a long time, is to update all CSLA nuget packages for each CSLA version update.

I think we need some new strategy by which some satellite packages, like MAUI, can be cleanly dropped from the build and releases.

I am interested in any thoughts or ideas, thank you.

[MaceySoftware]

I personally think this is fine due to following Microsofts untimely UI cutoffs.

My only question to you is would you expect backwards compatibility to work by design or by accident? For example if you are about to release CSLA 8.9.9 (random number) but the CSLA.MAUI package was last supported at version 8.4.5. As you're not updating the MAUI package anymore could I expect to use the latest CSLA (while your doing version 8) with the latest CSLA.MAUI?

If the answer is this wouldn't be supported then as long as this is documented somewhere I am personally fine with it.

[rockfordlhotka]

I am not sure of the answer.

Csla.Xaml (for MAUI) has a dependency on Csla.dll. I am guessing that it can't bind to a newer version of Csla.dll from a newer Csla nuget package.

Maybe there's a way to do the project reference so it can float to newer versions?

[MaceySoftware]

The reason I asked the question is if my app used MAUI and I upgraded to the highest version supported (8.4.5 in this example) and then a security vulnerability was discovered and was patched in 8.9.9 how could I upgrade my app to in corporate the security vulnerability.

Would I have to rewrite my whole UI to remove the security vulnerability or branch CSLA and handle the fix myself (this could potentially make it harder on myself to upgrade to a later version in the future)

[Bowman74]

I'm not surprised by this as it has existed in one way or another for Xamarin and Xamarin Forms long before MAUI became a thing. iOS, Mac Catalyst and Android are all on release cycles Microsoft does not control and require updates to MAUI to happen outside of the normal .Net releases, many of them happening day one of the platform releases. I was surprised when MAUI was first announced being tied to .Net, the .Net release clock could never work. Of course, that didn't last long and now MAUI releases happen off cycle.

Apple almost forces you to update your MAUI in order to tie into the latest Xcode version. While downloading an older Xcode version is possible Apple makes is a pain and we will say highly encourages you to update. As a result the current MAUI version is normally tied to the latest Xcode version and when a new version of Xcode is released, so is a new version of MAUI. This is why old .Net versions of MAUI are retired so early, it is a pain to keep updating them in perpetuity to deal with the latest 3rd party SDKs.

What do I think this likely means for CSLA.MAUI? Likely that it should be on its own release cycle and a new one out whenever MAUI is updated, independent of when CSLA is released. The version of CSLA it is tied to should depend on the version of .Net selected. i.e. if they are using .Net 8, CSLA.MAUI should require some version of CSLA 8.x, i.e. CSLA Version >= 8.* As you know nuget allows this with floating versions so it should need to have a particular version of CSLA to work, we can just say it needs to be greater or equal to version XYZ.

We would then use multi targeting in the nuget packages to have a compiled version of CSLA.MAUI that targets .Net 9.x and that would presumable have a dependency on CSLA 9.x, i.e. CSLA Version >= 9.*. Which I also assume means that until CSLA for .Net 9 is released they should be using MAUI targetting .Net 8.

[rockfordlhotka]

Thank you @Bowman74, this is the sort of input I was hoping for.

I think what I'm hearing is that the answer is to split the creation of (at least) the Csla.Xaml for MAUI into its own build/package pipeline.

It shares code with the WPF project as well, so could be difficult to move to its own repo - at least not without using fancy GitHub features to share code files across repos.

[Bowman74]

@rockfordlhotka I was thinking about this more and did a little research into the versioning of MAUI.

For CSLA.MAUI referencing MAUI (for example, Microsoft.Maui.Controls, Microsoft.Maui.Controls.Compatibility)
Here is the interesting thing, MAUI does not normally do minor versions. MS left open for the possibility of it, but rarely does so. So the reference from the CSLA.MAUI project and in the Nuget package should be:
<PackageReference Include="Microsoft.Maui.Controls" Version="9.0.*" /> and similar in the nuget package reference.

NOTE: making the project reference a wildcard mostly just makes it so it pull the latest package for the build, the important bit for the consumers of CSLA will be the floating nuget package reference

https://learn.microsoft.com/en-us/nuget/concepts/package-versioning?tabs=semver20sort
https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution

From a changing MAUI side you would only have to create a new version of CSLA.MAUI once when .net 9 or .net 10 is released. If there is a .Net MAUI 9.1.xxx, then yes that would be a breaking MAUI change and would need a new release. However, most non major version releases of MAUI would not trigger a need to redeploy CSLA.MAUI.

You should do a release of CSLA.MAUI as soon as a new major version of .NET is released, even if it is referencing the old .Net framework versions of CSLA. Probably no code changes would be required to CSLA.MAUI other than the required MAUI packages reference. This would allow the new version of VS to be used immediately when released while still using the old version of CSLA. it looks like you may already do this with <ItemGroup Condition="$(TargetFramework.StartsWith(&quot;net9&quot;))"> in the project file.

https://dotnet.microsoft.com/en-us/platform/support/policy/maui

For CSLA.MAUI referencing CSLA
I'd take a very similar stance. When CSLA 9 is released you would need a new version of CSLA.MAUI. I'm assuming minor CSLA releases are breaking CSLA changes so would require a new version of CSLA MAUI to be deployed as well. But point changes in CLSA would not.

So the nuget version reference in the nuget package to CSLA would look something like:
Version >= 9.0.x
When CSLA 9.1 is released a new version of CSLA.MAUI would also be released with nuget reference to CSLA being (the only real change may be the version of CSLA referenced):
Version => 9.1.x

NOTE: I looks like CSLA.MAUI is currently doing a project reference to CSLA in the csproj. The nuget reference would need to be a sliding CSLA package reference as above. Leaving the CSLA.MAUI csproj to CSLA as a project reference may work but since these would be on different release schedules, it may not as it may could pull in unreleased CSLA code when there is a MAUI reason for a new package (i.e. like wanting to do a new CSLA.MAUI release when .Net 9 MAUI is released and there being unreleased CSLA changes that also cascaded into CSLA.MAUI). This could almost certainly be managed by a branching scheme, leaving the CSLA project reference as is.

Overall a new version of CSLA.MAUI would only need to be released when:

• There is a major version of MAUI released (I.e. a new version of .Net)
• The unlikely event of a minor version of MAUI being released
• Major and minor CSLA releases (assuming minor releases represent breaking CSLA changes)
• There is a bug/change in CSLA.MAUI itself that requires a new release

Based on what I have read above on what the problem is, I think this will do it. This will also mean some CSLA releases will not need a release of CSLA.MAUI, any point releases wouldn't anyway. If minor releases do not represent breaking changes, let me know what does and we can figure something else out.

I don't know as much about your package building process. What I guess would need to happen to keep it all in one repo (without using Git submodules which I hear is ugly) is your current build process wound need a way to conditionally include or exclude CSLA.MAUI from the build and the ability to build CSLA.MAUI alone. Also if the build process is setting the version numbers for the project files and nuget packages, they would have to do it differently in CSLA.MAUI to match the scheme laid out earlier in this post. But as I said, I'm not sure how your release build and package process(es) work.

As an aside if you want ever want to noodle things over from a MAUI perspective, just make me aware of the post and I'll chime in. Opinions, I always have them. :) (particularly if it requires a little research like this one!)

[Bowman74]

@rockfordlhotka
One last thing, since CSLA.MAUI would now disconnected in many ways from the CSLA release cycle, if there is a new minor version of CSLA that does not cause a change in the CSLA.MAUI code, the new Release of CSLA.MAUI should allow either the new or old version of CSLA to be referenced. I.e. we should have a package range that includes all usable CSLA package versions.

This will ensure the latest version of CSLA.MAUI is always usable by any compatible CSLA version as the CSLA.MAUI releases will happen due to MAUI changes too. The last thing we want to do is force them to upgrade their version of CSLA simply because an unrelated change in MAUI caused a new CSLA.MAUI version to be released.