forked from xamarin/xamarin-macios
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Make.versions
148 lines (133 loc) · 6.36 KB
/
Make.versions
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
#
# A release branch requires updating the following six variables at the bottom of this file:
#
# IOS_PACKAGE_VERSION (major/minor/revision #)
# MAC_PACKAGE_VERSION (major/minor/revision #)
#
# IOS_NUGET_VERSION (major/minor/patch #)
# TVOS_NUGET_VERSION (major/minor/patch #)
# WATCHOS_NUGET_VERSION (major/minor/patch #)
# MACOS_NUGET_VERSION (major/minor/patch #)
#
# Update version numbers on main as well, to the next version
#
#
# ** Version numbers **
#
# Versions are defined as: Major.Minor.Revison.Build
#
# Major/minor (first/second numbers - max 2 digits each):
# - Bump for major/minor releases.
#
# Revision (third number - max 2 digits):
# - Reset to 0 after a major or minor bump (do not use 99 for Xcode preview
# branches (use 0 instead), because otherwise we can't bump it further if
# needed).
# - Bump for service releases and previews.
# - Bump if commit distance becomes > 999.
# - Can also be bumped for other reasons (in particular there's no correlation
# between Preview/Service Release #X and Revision #Y).
# - Bumping revision to a high enough number to make it clear that there's
# no correlation is a valid reason to bump.
# - The revision must be bumped at the same time for both iOS and Mac
# (otherwise the commit distance will differ).
# - Also bump if the [IOS|MAC]_PACKAGE_VERSION lines change for any other
# reason (otherwise we end up with repeating version numbers, since the
# commit distance would restart at 0, while the other numbers wouldn't
# change).
# - Any other problem can also usually be solved by bumping the revision.
# - Do not refactor the revision to a separate variable, because the reason
# bumping the revision is a general solution for many problems is that it
# also resets the commit distance (which wouldn't happen if the revision was
# refactored to a separate variable).
#
# Build (fourth number - max 3 digits):
# - Automatically calculated as the number of commits since the last time any
# of the other three numbers changed (technically since the corresponding
# line changed in git).
#
IOS_PACKAGE_VERSION=17.3.0.$(IOS_COMMIT_DISTANCE)
MAC_PACKAGE_VERSION=9.3.0.$(MAC_COMMIT_DISTANCE)
#
# ** NuGet package version numbers **
#
# See dotnet/VERSIONS.md.
#
# Rules:
# * The first two numbers represent the major and minor version of the corresponding OS.
# * A third number will be added later (the commit distance).
#
# IMPORTANT: There must be *no* managed API differences unless the two first
# numbers (major.minor) changes.
# WARNING: Do **not** use versions higher than the available Xcode SDK or else we will have issues with mtouch (See https://github.com/xamarin/xamarin-macios/issues/7705)
IOS_NUGET_OS_VERSION=17.2
TVOS_NUGET_OS_VERSION=17.2
WATCHOS_NUGET_OS_VERSION=10.2
MACOS_NUGET_OS_VERSION=14.2
MACCATALYST_NUGET_OS_VERSION=17.2
# In theory we should define the default platform version if it's not specified in the TFM. The default should not change for a given .NET version:
# * We release support for iOS 14.5 with .NET 6
# * Apple releases iOS 15.0, we're still using .NET 6. This default continues to be iOS 14.5
# * .NET 7 is shipped, and at this point we bump the default to iOS 15.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 target platform version.
#
# Here we list all the releases we support for each platform.
#
# Format: space-separated list of TargetFramework-OSVersion
#
# Example:
#
# SUPPORTED_API_VERSIONS_IOS=net8.0-17.0 net8.0-17.2
#
# This means the iOS workload shipped from the current branch supports projects with:
# <TargetFramework>net8.0-17.0</TargetFramework>
# and
# <TargetFramework>net8.0-17.2</TargetFramework>
# and even:
# <TargetFrameworks>net8.0-17.0;net8.0-17.2</TargetFrameworks>
#
# When shipping support for a preview Xcode, we might add entries here for a preview release into a stable release.
#
# Example:
#
# SUPPORTED_API_VERSIONS_IOS=net9.0-18.0
#
# If the current branch is stable .NET 8 using Xcode 15.0 (aka iOS 17.0), this
# would add support for trying the preview release by doing:
#
# <TargetFramework>net9.0-18.0</TargetFramework>
# <EnablePreviewFeatures>true</EnablePreviewFeatures>
#
# Note that any SUPPORTED_API_VERSIONS entry below for older OS versions need a corresponding entry in
# the eng/Version.Details.xml and eng/Versions.props files.
#
# First add the versions for the current branch. DO NOT TOUCH THIS. Add older branches below.
SUPPORTED_API_VERSIONS_IOS=$(DOTNET_TFM)-$(IOS_NUGET_OS_VERSION)
SUPPORTED_API_VERSIONS_TVOS=$(DOTNET_TFM)-$(TVOS_NUGET_OS_VERSION)
SUPPORTED_API_VERSIONS_MACOS=$(DOTNET_TFM)-$(MACOS_NUGET_OS_VERSION)
SUPPORTED_API_VERSIONS_MACCATALYST=$(DOTNET_TFM)-$(MACCATALYST_NUGET_OS_VERSION)
# Add older versions here!
SUPPORTED_API_VERSIONS_IOS+=$(DOTNET_TFM)-17.0
SUPPORTED_API_VERSIONS_TVOS+=$(DOTNET_TFM)-17.0
SUPPORTED_API_VERSIONS_MACOS+=$(DOTNET_TFM)-14.0
SUPPORTED_API_VERSIONS_MACCATALYST+=$(DOTNET_TFM)-17.0