8b888f0375
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.2 * Microsoft.iOS.Ref.net8.0_17.2 * Microsoft.iOS.Runtime.ios-arm64.net8.0_17.2 * Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.2 * Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.2 * tvOS * Microsoft.tvOS.Sdk.net8.0_17.2 * Microsoft.tvOS.Ref.net8.0_17.2 * Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.2 * Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.2 * Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.2 * Mac Catalyst * Microsoft.MacCatalyst.Sdk.net8.0_17.2 * Microsoft.MacCatalyst.Ref.net8.0_17.2 * Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.2 * Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.2 * macOS * Microsoft.macOS.Sdk.net8.0_14.2 * Microsoft.macOS.Ref.net8.0_14.2 * Microsoft.macOS.Runtime.osx-x64.net8.0_14.2 * Microsoft.macOS.Runtime.osx-arm64.net8.0_14.2 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.2 * 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.2`, `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.2 * 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.2`, 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 |
||
---|---|---|
.. | ||
.gitignore | ||
Makefile | ||
README.md | ||
diff-bundles.sh | ||
merger.cs | ||
report-status.sh |
README.md
New Releases
Inside Make.config
update the APIDIFF_REFERENCES=
line to point to the bundle.zip
URL of the currently stable version. E.g.
The links from our CI will be from bosstoragemirror.blob.core.windows.net
, but
replace the domain name with dl.internalx.com
, so the URL looks like this:
APIDIFF_REFERENCES=https://dl.internalx.com/wrench/jenkins/d15-9/2dc06c712629feeb179ed112a590d9922caac6e7/53/package/bundle.zip
New Revisions
On the bots each revision rebuilds every assemblies. Each of them will be compared to the downloaded stable version from APIDIFF_REFERENCES
. Any changes (addition/removal) to the public API will be reported in HTML files.
This can be done manually with make
. The .\diff\
directory will contain the diffs in HTML format.
The helper make merge
target creates a single api-diff.html
file (from all the diff\*.html
files) that be used for the documentation web site.
GitHub token
It's required to provide a GitHub PAT, with scope read:user
and
read:org
, in order to download the API reference files. The PAT can be created
here.
This can be provided in two ways:
- Create a file named
~/.config/AUTH_TOKEN_GITHUB_COM
, and add the PAT to this file (the file must contain only the PAT, and nothing else). This is the recommended way. - Export the PAT as the
AUTH_TOKEN_GITHUB_COM
environment variable.