xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/Make.versions

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

Try to make version numbers clearer, and establish some ground rules. (#4927)
2018-10-04 20:49:26 +03:00
#
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
# A release branch requires updating the following six variables at the bottom of this file:
Try to make version numbers clearer, and establish some ground rules. (#4927)
2018-10-04 20:49:26 +03:00
#
# IOS_PACKAGE_VERSION (major/minor/revision #)
# MAC_PACKAGE_VERSION (major/minor/revision #)
#
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
# IOS_NUGET_VERSION (major/minor/patch #)
# TVOS_NUGET_VERSION (major/minor/patch #)
# WATCHOS_NUGET_VERSION (major/minor/patch #)
# MACOS_NUGET_VERSION (major/minor/patch #)
#
Rename master to main. (#8851) * Fix links that point to master to point to main instead. * Implement support in the sample tester for specifying the default branch for each sample repo. * Fix various text / documentation to say 'main' instead of 'master.' * Push to 'main' instead of 'master' in xamarin-macios-data. * Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'. * Fix various CI to use 'main' instead of 'master'. * Bump maccore New commits in xamarin/maccore: * xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233) Diff: https://github.com/xamarin/maccore/compare/424fa2614873c7415cf0407d2389335cba0b6c79..ed6d1468221f2220cd3f39294427160f0d3fbced
2020-06-16 16:51:44 +03:00
# Update version numbers on main as well, to the next version
Try to make version numbers clearer, and establish some ground rules. (#4927)
2018-10-04 20:49:26 +03:00
#
#
# ** 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).
#
[Xcode 15.2] Bump to Xcode 15.2 (#19785) This is a manual and squashed backport of https://github.com/xamarin/xamarin-macios/pull/19717 and it was updated to use Xcode 15.2 since Xcode 15.2 contains the same SDKs as Xcode 15.1 but Xcode 15.2 has visionOS SDK and it is the new stable release from Apple. --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2024-01-12 12:56:22 +03:00
IOS_PACKAGE_VERSION=17.3.0.$(IOS_COMMIT_DISTANCE)
MAC_PACKAGE_VERSION=9.3.0.$(MAC_COMMIT_DISTANCE)
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
#
# ** NuGet package version numbers **
#
# See dotnet/VERSIONS.md.
#
# Rules:
# * The first two numbers represent the major and minor version of the corresponding OS.
Adjust versioning scheme for .NET to make the third field the commit distance. (#14923) Adjust our versioning scheme so that the NuGet version is `Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish version>") causes problems on branches producing stable builds, because each new commit would end up with the same NuGet version, and we wouldn't be able to push those to a NuGet feed because there might already be an existing version there. By using the commit distance in the NuGet version we ensure that every commit has a different version.
2022-05-10 10:28:39 +03:00
# * A third number will be added later (the commit distance).
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
#
[dotnet] Use only the first two parts of our product version as the assembly version. (#14846) This is a follow up to 92ee92eeb57f470eea28a2119f7d329be6a24030, where we changed the assembly version from four digits to three digits (i.e not include the build number), because our managed API should be identical for (released) versions where only the build number changes. In this PR we go a bit further, because we're not supposed to have any API differences unless the first two parts of the product version changes, which means that we should only use need the two first parts of our product version as the assembly version.
2022-05-03 11:07:11 +03:00
# IMPORTANT: There must be *no* managed API differences unless the two first
# numbers (major.minor) changes.
Create and publish .NET NuGet packages. (#8576) Create the various NuGet packages to support .NET 5+. The packages are currently empty (and not very useful), but the actual content will come later. The current set of NuGet packages are (this list is duplicated for each platform: iOS, tvOS, watchOS and macOS): * Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an MSBuild Project SDK. Will eventually contain all the build logic. Might also eventually contain other tools (mlaunch, bgen, etc.), but these might also end up in a different package. * Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly. * Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files (libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.): The NuGets built on CI are automatically published to a NuGet feed. The versioning for the NuGet packages required a few changes: OS bumps are now changed in Make.versions instead of Make.config (this is explained in the files themselves as well).
2020-05-13 16:23:29 +03:00
# 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)
[Xcode 15.2] Bump to Xcode 15.2 (#19785) This is a manual and squashed backport of https://github.com/xamarin/xamarin-macios/pull/19717 and it was updated to use Xcode 15.2 since Xcode 15.2 contains the same SDKs as Xcode 15.1 but Xcode 15.2 has visionOS SDK and it is the new stable release from Apple. --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2024-01-12 12:56:22 +03:00
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
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
[dotnet] Stop using a separate default platform version. (#19754) In theory we should define the default platform version if it's not specified in the TFM, and this default should not change for a given .NET version: * We release support for iOS 17.0 with .NET 8 * Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0 * .NET 9 is shipped, and at this point we bump the default to iOS 18.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.
2024-01-09 11:47:07 +03:00
# 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:
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
# * 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
[dotnet] Stop using a separate default platform version. (#19754) In theory we should define the default platform version if it's not specified in the TFM, and this default should not change for a given .NET version: * We release support for iOS 17.0 with .NET 8 * Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0 * .NET 9 is shipped, and at this point we bump the default to iOS 18.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.
2024-01-09 11:47:07 +03:00
# 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.
[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
[maestro] Subscribe to the .NET 7 channel to get bumps for our own .NET 7 packages for .NET 8. (#16859) We need the latest released version numbers for the previous .NET version so that we can reference and consume those when building projects using the corresponding target framework. Luckily we have a system for keeping dependencies up-to-date, so let's use it to notify the current branch for any updates to the release branch for the previous .NET version.
2022-11-23 09:34:40 +03:00
[dotnet] Add warning when the TargetPlatformVersion isn't supported (#19901) We've used to ignore the target platform version (the "17.0" part in "net8.0-ios17.0") since our initial .NET relaese - customers could specify any valid OS version between the minimum and maximum versions, and we'd completely ignore the value [1]. The purpose of the target platform version is to specify which bindings to choose: "net8.0-ios17.0" would mean that the developer wants packages that have bindings for iOS 17.0 (and earlier iOS versions, but not later iOS versions). So saying "net8.0-ios11.0" would technically mean that the developer would want our bindings for iOS 11.0 (and earlier iOS versions, but not later iOS versions). The problem is that we don't ship any such thing... we shipped iOS 17.0 bindings in .NET 8, and that's it, you can't choose to build with something that does *not* have bindings for iOS 17.0. This will change with multi-targeting: we'll support *some* matrix of bindings. For instance, we might want to support the OS version we shipped initial support in any given .NET release + the latest OS version. For example, we might want to support both of these: * net8.0-ios17.0 * net8.0-ios17.2 This means that the target platform version (17.0/17.2) can't keep staying ignored. There was an somewhat related issue with the `SdkSupportedTargetPlatformVersion`, where we're now able to distinguish between old versions we no longer support and new versions that limits the valid values for TargetPlatformVersion (see 74d83ca7e30b40c5d7224ca0be35c47b64d9f82b). We've already taken advantage of this to properly annotate every version, even in .NET 8 (in a future service update), because the dotnet/sdk change required to understand the new annotations (and ignore old versions in the `SdkSupportedTargetPlatformVersion` item group) won't be shipped until .NET 9, so this won't be a breaking change in .NET 8. However, we'd still like to give customers a heads up that their project files need to change, so this PR adds a warning (that tells developers what to do), and then in .NET 9 we'll make the warning an error instead. Side note: Android is also making an invalid target platform version an error in .NET 9: https://github.com/xamarin/xamarin-android/pull/8569. [1]: We'd ignore the value for executable projects. It did have an effect for library projects that were packed into NuGets: the target platform version would be stored in the NuGet.
2024-01-25 11:23:03 +03:00
#
# 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!
[dotnet] Multi target with Xcode 15.0 (#20155) Add multi-targeting support for our initial .NET 8 packs (for Xcode 15.0). This means a library/binding project can do: ```xml <TargetFrameworks>net8.0-ios17.0;net8.0-ios17.2</TargetFrameworks> ``` and the library will be built in two varieties: once using our iOS 17.0 bindings, and once using our iOS 17.2 bindings. An app project can also do: ```xml <TargetFramework>net8.0-ios17.0</TargetFramework> ``` to build with the iOS 17.0 bindings (which is typically not very useful, since building with the latest iOS SDK is usually best).
2024-02-28 11:03:53 +03:00
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