Application-update targeting and release selection¶
Release targeting determines eligibility, while publication time determines which eligible release wins.
Target types¶
| Target | Required value | Matching behavior |
|---|---|---|
| Global | No target rows | Eligible for every request with the matching application and channel. |
| SITE | Numeric TEKControl site ID | Exact match with the site ID supplied by the client. |
| DEVICE | Device identifier | Case-insensitive match with deviceIdentifier, or the request's deviceId fallback. |
SITE values are validated only as digits; the editor does not verify that the site exists. DEVICE values are checked only for nonblank text; the editor does not verify that a device is registered, unique, or uses that identifier when requesting updates.
Multiple targets are alternatives. A release is eligible when the request matches any SITE or DEVICE target. Duplicate target rows are not prevented and add no additional priority.
Selection sequence¶
For an update to be returned:
- Application Code must match, case-insensitively.
- Channel must match, case-insensitively. A blank requested channel becomes stable.
- The release must be Enabled.
- Published time must be blank or at or before the current time.
- Expiration must be blank or after the current time.
- The release must be Global or match the request's site or device.
- Of all eligible releases, the newest Published time wins; record ID breaks a tie.
- The selected release version must be newer than the client's current version.
- If Minimum Current Version is set and the client reports a version below it, no update is returned.
Global and targeted precedence¶
Targeted releases do not automatically outrank global releases. A newer eligible global release can win over an older targeted release for the same application and channel. Likewise, a newer targeted release can win for matching targets while nonmatching devices receive the newest global release.
Use separate pilot or beta channels when you need stable and unambiguous rollout isolation. If the client cannot change channels, coordinate publish timestamps carefully and test the exact selection combination.
Minimum Current Version¶
Minimum Current Version is a lower compatibility bound, not the version that triggers an upgrade.
Example: a release at 5.0.0 with minimum 4.2.0 is unavailable to a client reporting 4.1.9. That device needs an eligible intermediate release or a manual remediation path before it can receive 5.0.0.
If the client omits Current Version, the minimum-version check is skipped. Supported clients should therefore report an accurate version.
Scope examples¶
Pilot one device¶
Use the pilot channel and one DEVICE target. Confirm the client requests pilot and sends the exact device identifier.
Pilot one site¶
Use the pilot channel and one SITE target. Confirm all intended clients send the correct site ID and no shared device should remain outside the site's rollout.
Promote to stable¶
Create or enable the validated package on stable with a later publication time. Do not merely retarget a production pilot record if retaining pilot evidence and rollback clarity matters.
Stage an intermediate upgrade¶
Publish the intermediate version for older clients. After confirming they meet the lower bound, make the final release eligible. Carefully coordinate publication order because only the newest eligible release is evaluated before the minimum-version result is returned.