xamarin-macios/Make.versions

95 строки
4.1 KiB
Plaintext
Исходник Обычный вид История

#
# 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=16.1.1.$(IOS_COMMIT_DISTANCE)
MAC_PACKAGE_VERSION=9.0.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)
# When bumping the major macOS version in MACOS_NUGET_VERSION also update the macOS version where we execute on bots in jenkins/Jenkinsfile (in the 'node' element)
IOS_NUGET_OS_VERSION=16.1
TVOS_NUGET_OS_VERSION=16.1
WATCHOS_NUGET_OS_VERSION=9.1
2022-06-07 09:45:47 +03:00
MACOS_NUGET_OS_VERSION=13.0
MACCATALYST_NUGET_OS_VERSION=16.1
# Defines 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
DEFAULT_TARGET_PLATFORM_VERSION_IOS=16.1
DEFAULT_TARGET_PLATFORM_VERSION_TVOS=16.1
DEFAULT_TARGET_PLATFORM_VERSION_WATCHOS=9.1
2022-06-07 09:45:47 +03:00
DEFAULT_TARGET_PLATFORM_VERSION_MACOS=13.0
DEFAULT_TARGET_PLATFORM_VERSION_MACCATALYST=16.1
[dotnet] Rework KnownFrameworkReference so that 'net6.0-*' TargetFrameworks work when building with .NET 7. Fixes #15375. The KnownFrameworkReference now references the exact versions of the ref and runtime packs we're shipping with the sdk pack, instead of telling the build to use whatever version is defined in the workload. Then in the workload we specify the latest released version of the .NET 6 for the ref and runtime packs. Finally we add an aliased sdk pack, which points to the .NET 6 sdk pack, and when we're building a .NET 6 TargetFramework we load this aliased sdk pack instead of the one we're shipping with this workload. Putting this together means that: * When we're building a .NET 7 TargetFramework, we load the sdk pack shipped with the workload, which adds a KnownFrameworkReference which references the ref and runtime packs with the same version as the sdk pack. * When we're building a .NET 6 TargetFramework, we load the (aliased) sdk pack which points to the latest stable .NET 6 sdk pack. That sdk pack will add a KnownFrameworkReference that tells the build to use the ref and runtime pack versions specified in the workload - which are now pointing to the .NET 6 ref and runtime pack versions. Thus we use the .NET 6 sdk, ref and runtime packs when building a .NET 6 TargetFramework, and we use the .NET 7 sdk, ref and runtime packs when building a .NET 7 TargetFramework. According to the workload design spec [1], this is supposed to be implemented by using aliased ref and runtime packs, but that doesn't work due to https://github.com/dotnet/sdk/issues/26384. Fixes https://github.com/xamarin/xamarin-macios/issues/15375. [1]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md?rgh-link-date=2022-06-30T08%3A25%3A10Z#side-by-side-workload-pattern
2022-06-30 14:04:04 +03:00
# These variables must be updated whenever we release a new stable version into .NET 6
NET6_IOS_NUGET_VERSION_NO_METADATA=16.0.526
NET6_TVOS_NUGET_VERSION_NO_METADATA=16.0.526
[dotnet] Rework KnownFrameworkReference so that 'net6.0-*' TargetFrameworks work when building with .NET 7. Fixes #15375. The KnownFrameworkReference now references the exact versions of the ref and runtime packs we're shipping with the sdk pack, instead of telling the build to use whatever version is defined in the workload. Then in the workload we specify the latest released version of the .NET 6 for the ref and runtime packs. Finally we add an aliased sdk pack, which points to the .NET 6 sdk pack, and when we're building a .NET 6 TargetFramework we load this aliased sdk pack instead of the one we're shipping with this workload. Putting this together means that: * When we're building a .NET 7 TargetFramework, we load the sdk pack shipped with the workload, which adds a KnownFrameworkReference which references the ref and runtime packs with the same version as the sdk pack. * When we're building a .NET 6 TargetFramework, we load the (aliased) sdk pack which points to the latest stable .NET 6 sdk pack. That sdk pack will add a KnownFrameworkReference that tells the build to use the ref and runtime pack versions specified in the workload - which are now pointing to the .NET 6 ref and runtime pack versions. Thus we use the .NET 6 sdk, ref and runtime packs when building a .NET 6 TargetFramework, and we use the .NET 7 sdk, ref and runtime packs when building a .NET 7 TargetFramework. According to the workload design spec [1], this is supposed to be implemented by using aliased ref and runtime packs, but that doesn't work due to https://github.com/dotnet/sdk/issues/26384. Fixes https://github.com/xamarin/xamarin-macios/issues/15375. [1]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md?rgh-link-date=2022-06-30T08%3A25%3A10Z#side-by-side-workload-pattern
2022-06-30 14:04:04 +03:00
NET6_WATCHOS_NUGET_VERSION_NO_METADATA=8.5.447
NET6_MACOS_NUGET_VERSION_NO_METADATA=12.3.470
NET6_MACCATALYST_NUGET_VERSION_NO_METADATA=15.4.470