-
Notifications
You must be signed in to change notification settings - Fork 522
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
[dotnet] Rename packs to contain target framework. #19765
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Marking as |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This pull request updates the following dependencies - **Subscription**: 3ba82e10-e94b-4c1c-df8b-08dc11e0730b - **Build**: 20231204.1 - **Date Produced**: December 4, 2023 9:51:25 AM UTC - **Commit**: 88bdab7 - **Branch**: refs/heads/release/7.0.3xx - **Updates**: - **Microsoft.iOS.Sdk**: [from 16.4.7099 to 16.4.7129][4] [4]: c70a2f5...88bdab7
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This reverts commit 5cd497a.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
📚 [PR Build] Artifacts 📚Packages generatedView packagesPipeline on Agent |
💻 [PR Build] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Ventura (13) passed 💻✅ All tests on macOS M1 - Mac Ventura (13) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Big Sur (11) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Monterey (12) passed 💻✅ All tests on macOS M1 - Mac Monterey (12) passed. Pipeline on Agent |
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
🔥 Failed to compare API and create generator diff 🔥 Failed to update apidiff references Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 170 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
VS insertion test came back green. API diff is expected to break, since this is a major change and comparison with the previous commit is difficult. API diff should work again in any subsequent changes. |
…ramework. This is the first step towards [multi-targeting support][1]. In order to support multi-targeting, it must be possible to install several versions of our packs simultaneously, and that also means that it becomes a lot easier to visualize and work with the version we want to support if the packs were named in a helpful way. In particular, this PR changes the sdk, ref and runtime pack names to contain the target framework + target platform version. This will be the new names: * iOS * Microsoft.iOS.Sdk.net8.0_17.0 * Microsoft.iOS.Ref.net8.0_17.0 * Microsoft.iOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.0 * tvOS * Microsoft.tvOS.Sdk.net8.0_17.0 * Microsoft.tvOS.Ref.net8.0_17.0 * Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.0 * Mac Catalyst * Microsoft.MacCatalyst.Sdk.net8.0_17.0 * Microsoft.MacCatalyst.Ref.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.0 * macOS * Microsoft.macOS.Sdk.net8.0_14.0 * Microsoft.macOS.Ref.net8.0_14.0 * Microsoft.macOS.Runtime.osx-x64.net8.0_14.0 * Microsoft.macOS.Runtime.osx-arm64.net8.0_14.0 There are two main benefits to renaming the packs: * It becomes a lot easier to understand which versions we support when we support multi-targeting. For example, say we want to support: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net9.0_18.0` (the exact version number for each pack wouldn't be important). If we didn't change the pack names, we'd need to track the exact versions of the Microsoft.iOS.Sdk pack, mapping them to the correct target framework + target platform version we want to support. * It'll be possible to add maestro subscriptions between versions. Given the previous example: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 The branch producing `net9.0-ios8.0` could have a maestro subscription on the branches producing `net7.0-ios17.0` and `net7.0-ios17.0`, automatically bumping the versions whenever those branches have any changes. This would be rather annoying to keep track of and bump manually. [1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md Backport of #19765.
…ramework. (#20171) This is the first step towards [multi-targeting support][1]. In order to support multi-targeting, it must be possible to install several versions of our packs simultaneously, and that also means that it becomes a lot easier to visualize and work with the version we want to support if the packs were named in a helpful way. In particular, this PR changes the sdk, ref and runtime pack names to contain the target framework + target platform version. This will be the new names: * iOS * Microsoft.iOS.Sdk.net8.0_17.0 * Microsoft.iOS.Ref.net8.0_17.0 * Microsoft.iOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.0 * tvOS * Microsoft.tvOS.Sdk.net8.0_17.0 * Microsoft.tvOS.Ref.net8.0_17.0 * Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.0 * Mac Catalyst * Microsoft.MacCatalyst.Sdk.net8.0_17.0 * Microsoft.MacCatalyst.Ref.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.0 * macOS * Microsoft.macOS.Sdk.net8.0_14.0 * Microsoft.macOS.Ref.net8.0_14.0 * Microsoft.macOS.Runtime.osx-x64.net8.0_14.0 * Microsoft.macOS.Runtime.osx-arm64.net8.0_14.0 There are two main benefits to renaming the packs: * It becomes a lot easier to understand which versions we support when we support multi-targeting. For example, say we want to support: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net9.0_18.0` (the exact version number for each pack wouldn't be important). If we didn't change the pack names, we'd need to track the exact versions of the Microsoft.iOS.Sdk pack, mapping them to the correct target framework + target platform version we want to support. * It'll be possible to add maestro subscriptions between versions. Given the previous example: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 The branch producing `net9.0-ios8.0` could have a maestro subscription on the branches producing `net7.0-ios17.0` and `net7.0-ios17.0`, automatically bumping the versions whenever those branches have any changes. This would be rather annoying to keep track of and bump manually. [1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md Backport of #19765.
…ramework. (#20171) This is the first step towards [multi-targeting support][1]. In order to support multi-targeting, it must be possible to install several versions of our packs simultaneously, and that also means that it becomes a lot easier to visualize and work with the version we want to support if the packs were named in a helpful way. In particular, this PR changes the sdk, ref and runtime pack names to contain the target framework + target platform version. This will be the new names: * iOS * Microsoft.iOS.Sdk.net8.0_17.0 * Microsoft.iOS.Ref.net8.0_17.0 * Microsoft.iOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.0 * tvOS * Microsoft.tvOS.Sdk.net8.0_17.0 * Microsoft.tvOS.Ref.net8.0_17.0 * Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.0 * Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.0 * Mac Catalyst * Microsoft.MacCatalyst.Sdk.net8.0_17.0 * Microsoft.MacCatalyst.Ref.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.0 * Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.0 * macOS * Microsoft.macOS.Sdk.net8.0_14.0 * Microsoft.macOS.Ref.net8.0_14.0 * Microsoft.macOS.Runtime.osx-x64.net8.0_14.0 * Microsoft.macOS.Runtime.osx-arm64.net8.0_14.0 There are two main benefits to renaming the packs: * It becomes a lot easier to understand which versions we support when we support multi-targeting. For example, say we want to support: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net8.0_17.0`, `Microsoft.iOS.Sdk.net9.0_18.0` (the exact version number for each pack wouldn't be important). If we didn't change the pack names, we'd need to track the exact versions of the Microsoft.iOS.Sdk pack, mapping them to the correct target framework + target platform version we want to support. * It'll be possible to add maestro subscriptions between versions. Given the previous example: * net8.0-ios17.0 * net8.0-ios17.0 * net9.0-ios18.0 The branch producing `net9.0-ios8.0` could have a maestro subscription on the branches producing `net7.0-ios17.0` and `net7.0-ios17.0`, automatically bumping the versions whenever those branches have any changes. This would be rather annoying to keep track of and bump manually. [1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md Backport of #19765.
This is the first step towards multi-targeting support. In order to
support multi-targeting, it must be possible to install several versions of
our packs simultaneously, and that also means that it becomes a lot easier to
visualize and work with the version we want to support if the packs were named
in a helpful way.
In particular, this PR changes the sdk, ref and runtime pack names to contain
the target framework + target platform version.
This will be the new names:
iOS
tvOS
Mac Catalyst
macOS
There are two main benefits to renaming the packs:
It becomes a lot easier to understand which versions we support when we
support multi-targeting. For example, say we want to support:
In this case we'd ship packs for
Microsoft.iOS.Sdk.net8.0_17.0
,Microsoft.iOS.Sdk.net8.0_17.2
,Microsoft.iOS.Sdk.net9.0_18.0
(theexact version number for each pack wouldn't be important).
If we didn't change the pack names, we'd need to track the exact versions
of the Microsoft.iOS.Sdk pack, mapping them to the correct target
framework + target platform version we want to support.
It'll be possible to add maestro subscriptions between versions. Given the
previous example:
The branch producing
net9.0-ios8.0
could have a maestro subscription onthe branches producing
net7.0-ios17.0
andnet7.0-ios17.2
,automatically bumping the versions whenever those branches have any
changes.
This would be rather annoying to keep track of and bump manually.