.NET MAUI 6 has been unsupported for some time (preventing iOS 17 support)
frenzibyte opened this issue · 7 comments
We are currently targeting .NET MAUI 6 (i.e. net6.0-ios/net6.0-android), which has been "prematurely" out of support for some time now (see here for more information). Now, with both iOS 17 and Xcode 15's release, updates to the .NET iOS toolchain have only been offered to .NET MAUI 7 (starting at .NET SDK 7.0.402), and thus osu! and o!f cannot deploy to iOS 17 devices for the time being.
Until we move to .NET 7/8, I'm opening this issue thread to keep track of this limitation. I have also set up master...frenzibyte:osu-framework:ios-17-master to still be able to deploy to my devices in the interim.
which has been "prematurely" out of support for some time now
The page you linked promises 6 months of support after the release of a new version. .NET MAUI 6 reached EoL exactly 6 months after .NET MAUI 7 released, I don't see anything premature there. The oddity is that .NET 6 is supported while MAUI 6 isn't.
Since .NET releases yearly, and MAUI follows that cycle, that gives 12+6 = 18 months of support for MAUI, which matches the STS version of .NET. LTS versions (.NET 6, 8, 10...) get 3 years of support, but MAUI will always be at 18 months.
This basically invalidates the "long term" part of LTS for every .NET project targeting mobile, as every release will get 18 months flat. We will have to update to the latest .NET version 6 months after its release. I don't see this being too bad, as we just bump a number, get a performance boost and new features.
which has been "prematurely" out of support for some time now
The page you linked promises 6 months of support after the release of a new version. .NET MAUI 6 reached EoL exactly 6 months after .NET MAUI 7 released, I don't see anything premature there.
Prematurely in relation to .NET 6’s lifetime itself, not with regards to what’s promised in that page.
Your discord message implies this is only for .NET 6, when in fact it applies to every LTS .NET version, including the upcoming .NET 8. So I wanted to clear this confusion and say that this will be a recurring problem if not dealt within 6 months of a new .NET release.
You're right, I misread their support policy.
Since .NET releases happen once a year, I think it wouldn't hurt to bump the SDK targets every now and then as you mentioned already.
One concern that was mentioned before is that, while bumping .NET affects performance positively, it could also likely affect it negatively (recall song select search becoming slow on .NET 5, and beatmap imports becoming extremely slow on macOS on .NET 5/6).
But it's still once per year, so I'm not sure if that concern holds much value given the time window.
I don't see this being too bad, as we just bump a number, get a performance boost and new features.
I'll just say that based on prior experience, this is naive thinking. .NET bumps almost invariably take much more effort than that. It's really not just "bumping a number", sometimes not entirely due to code issues itself, but also due to issues related to the tooling etc.
It's also a hard one to decide on. If you allow higher SDKs to run the project, we will inevitably get people with net6 and net7 installed side-by-side suddenly running into issues and reporting the project not working on a clean checkout. Which is why we have things hard-locked right now.
As long as we have global.json configured for the CLI to operate on .NET 7, we should hopefully not run into conflict from having both SDKs installed (assuming we update all projects together to .NET 7, not just part of them).