Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update how the default OS version is calculated for Apple platforms. #324

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rolfbjarne
Copy link
Member

Also change the corresponding example to use Android instead of iOS, because
it's not correct for iOS.

Also change the corresponding example to use Android instead of iOS, because
it's not correct for iOS.
@rolfbjarne
Copy link
Member Author

I'm also updating the docs: dotnet/docs#43089

Copy link
Member

@jonathanpeppers jonathanpeppers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The notes about Android look correct. For .NET 9, net9.0-android is net9.0-android35. If 36 came out in the middle of the year you would have to put net9.0-android36 in your project to use it.

rolfbjarne added a commit to xamarin/xamarin-macios that referenced this pull request Oct 21, 2024
…rsion for library projects. (#21343)

We must define the default platform version if it's not specified in the TFM, and according to the spec the default should not change for a given .NET version:

* We release support for iOS 18.0 with .NET 9
* Apple releases iOS 18.1, we're still using .NET 9. This default continues to be iOS 18.0
* .NET 10 is shipped, and at this point we bump the default to iOS 19.0

Basically: this should be the last OS version of the platform in question when the current major .NET version is first released to stable.

Ref: https://github.com/dotnet/designs/blob/8e6394406d44f75f30ea2259a425cb9e38d75b69/accepted/2020/net5/net5.md#os-versions

However, this doesn't work well for Apple platforms: Whenever Apple releases new Xcode versions, our existing workloads might not be compatible with the new Xcode. We'll of course ship updateds workload with support for the new Xcode, but defaulting to an older target platform version would mean that developers wouldn't get the new workload, they'd get the old one. This is exacerbated by the fact that Apple aggressively auto-updates Xcode on developers' machines: they might wake up one day to a broken build - the obvious fix ("dotnet workload update") doesn't fix anything - even if we've shipped updated workloads - because the default is to use the old one. They'd have to manually specify the target platform version in the target platform to get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8 workload) - and then update _again_ when the next Xcode comes around. At this point the point of having a sane default value is totally out the window, because everybody would have to specify (and continuously update) a platform version in their project files to keep their projects building.

So we've made the decision that the default target platform version is always the latest supported target platform version.

Given the previous example: once we've implemented and released support for iOS 18.1, the updated iOS workload will use 18.1 as the default TPV for iOS.

On the other hand, this turns out to be somewhat of a complication for library developers, because they typically don't need Xcode to build their projects, and if we auto-update their TargetPlatformVersion to the latest, then all their customers have to also update their workloads, which for some people end up being a rather nasty surprise (because with the above algorithm it happens without developer action). Thus we follow .NET's default platform version scheme for library projects: it won't change in minor .NET releases.

Related design/docs PRs:

* dotnet/docs#43089
* dotnet/designs#324
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants