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_COMenvironment variable.