Repository navigation
Expand file tree
/
Copy pathDirectory.Build.props
More file actions
139 lines (117 loc) · 7.77 KB
/
Copy pathDirectory.Build.props
File metadata and controls
139 lines (117 loc) · 7.77 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
<Project>
<PropertyGroup>
<!--
Package version is <native SDK version>.<binding revision>, matching the two platform
binding repositories this one sits on top of — sbokatuk/OpenTok.Net.iOS and
sbokatuk/OpenTok.Net.Android, both currently on Vonage's SDK 2.34.1.
OpenTokVersion is therefore not this repository's own choice: it is the version of the
*platform packages* being wrapped, and both must be on it. That is the point of stating it
once here — a façade whose two halves wrap different SDK generations is exactly the drift
this package exists to hide, and it would hide it silently.
The fourth component belongs to this repository and advances when the façade changes while
the platform packages stay put.
Starting at 1 is safe: the predecessor monorepo published OpenTok.Net up to 2.27.1.817 on
nuget.org under this package ID (plus the prerelease 2.27.1.900-beta.3.4; verified
2026-07-28 via https://api.nuget.org/v3-flatcontainer/opentok.net/index.json), and 2.34.1.1
sorts above every one of them. OpenTok.Net.Maui has never been published. Check that URL
before lowering any component — a version that does not sort above what is already published
makes the package invisible to `dotnet add package`.
-->
<OpenTokVersion>2.34.1</OpenTokVersion>
<OpenTokBindingRevision>5</OpenTokBindingRevision>
<VersionPrefix>$(OpenTokVersion).$(OpenTokBindingRevision)</VersionPrefix>
<!--
The platform packages this façade wraps, pinned exactly.
Written as literals rather than derived from $(OpenTokVersion): these are read by
.github/workflows/release.yml and by tests/OpenTok.Net.UnitTests with a plain sed/substring
match, neither of which evaluates MSBuild expressions — a `$(OpenTokVersion).1` here would
reach the release notes verbatim. They are also genuinely independent numbers, because each
binding repository advances its own fourth component on its own schedule; only the first three
components have to agree, and that is what the package tests assert.
Pinned, not floating: a range would let a consumer resolve a platform package this façade was
never built against. Bump by hand when a binding repository publishes something worth taking.
-->
<OpenTokIosPackageVersion>2.34.1.2</OpenTokIosPackageVersion>
<OpenTokAndroidPackageVersion>2.34.1.4</OpenTokAndroidPackageVersion>
</PropertyGroup>
<PropertyGroup>
<!--
Each platform's OS floor. Stated once here rather than per project because five things need
to agree on them — both packages, the sample, the device tests, and the README — and a façade
that claims to support an OS version the package underneath it does not simply fails to
restore, for whoever picks that version.
Neither number is a choice made in this repository:
* iOS 15.0 is OTXCFramework 2.34.1's own floor, per its podspec ("platforms": {"ios":
"15.0"}), raised from 13.0 by that SDK release.
* Android 24 is opentok-android-sdk's own minSdkVersion. The manifest merger rejects an app
manifest claiming anything lower outright, with AAPT2's uses-sdk:minSdkVersion error.
Re-check both against the platform binding repositories on every version bump; neither is
derivable from anything else here.
-->
<OpenTokSupportedIosVersion>15.0</OpenTokSupportedIosVersion>
<OpenTokSupportedAndroidVersion>24</OpenTokSupportedAndroidVersion>
<!--
Windows, where two different numbers are needed and conflating them is the usual mistake.
OpenTokWindowsSdkVersion (10.0.19041.0) is what the target framework is *built* against — the
Windows App SDK's floor for WinUI 3, and therefore not negotiable.
OpenTokSupportedWindowsVersion (10.0.17763.0) is where the result will *run*, and is .NET
MAUI's own floor. Setting the runtime floor to 19041 as well would refuse to install on
machines MAUI itself supports, for no gain.
-->
<OpenTokWindowsSdkVersion>10.0.19041.0</OpenTokWindowsSdkVersion>
<OpenTokSupportedWindowsVersion>10.0.17763.0</OpenTokSupportedWindowsVersion>
<!--
The Windows App SDK, which is what provides WinUI 3. Must match what OpenTok.Net.Win was built
against — both end up in one app, and two WinUI runtimes is not a thing that resolves quietly.
-->
<WindowsAppSdkVersion>2.3.1</WindowsAppSdkVersion>
<!--
The Windows head's own package. Exact, like the other two — see the comment on those, and note
the extra reason here: OpenTok.Net.Win carries the renderer that reads VideoFrame planes
directly, so a mismatched pair is not a version-skew inconvenience but a memory-safety one.
A released version, never one of the betas OpenTok.Net.Win's pr.yml publishes per pull-request
build. Because the pin is exact, the Windows jobs here cannot run until the pinned version
exists on nuget.org — restore fails with NU1102 and the whole Windows leg goes red for a reason
that has nothing to do with the change under review — and pinning the in-flight beta to get
past that is how the beta reaches a release: whatever is here when a tag is cut is what
consumers of the umbrella resolve, and a released package that depends on something built from
a branch is not a release. The platform repository publishes first and this one re-pins behind
it; the release notes for 2.34.1.4 spell out that ordering, and OpenTok.Net 2.34.1.2 is what
happens when it is not followed.
Set as this element's value and nowhere else in this file. Everything that reads these pins
outside MSBuild — build/pins.sh, build/check-upstream.sh, release.yml, pr.yml, the repository
consistency tests — matches the element textually and keeps the first hit, so a second one
written into a comment above the real pin *is* the pin as far as all of them are concerned.
That is not hypothetical: an example beta spelled out here in full had the daily upstream check
reporting this package as pinned to a prerelease nuget.org had never carried, while the
packages themselves were built against the release below it. RepositoryConsistencyTests now
asserts both halves — one occurrence per pinned property, and no prerelease in any of them.
-->
<OpenTokWinPackageVersion>2.34.1.4</OpenTokWinPackageVersion>
<!--
Vonage's own Windows SDK. Arrives transitively through OpenTok.Net.Win anyway; pinned here
because this façade compiles against OpenTok.Session and OpenTok.Publisher directly.
-->
<OpenTokClientPackageVersion>2.34.1</OpenTokClientPackageVersion>
<Authors>s.bokatuk</Authors>
<Company>s.bokatuk</Company>
<Copyright>Copyright © s.bokatuk</Copyright>
<PackageProjectUrl>https://github.com/sbokatuk/OpenTok.Net</PackageProjectUrl>
<RepositoryUrl>https://github.com/sbokatuk/OpenTok.Net</RepositoryUrl>
<RepositoryType>git</RepositoryType>
<!--
MIT covers the code in this repository. Vonage's own SDKs are distributed under their own SDK
licence terms, reached transitively through the platform binding packages; nothing is claimed
about them here.
-->
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
<PackageIcon>icon.png</PackageIcon>
<PackageReadmeFile>README.md</PackageReadmeFile>
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
<ContinuousIntegrationBuild Condition=" '$(GITHUB_ACTIONS)' == 'true' ">true</ContinuousIntegrationBuild>
</PropertyGroup>
</Project>