Plugin compatibility across server and runtime changes
Plugin compatibility requires a supported relationship among host interfaces, runtime dependencies, platform assets and persisted data, not merely a successfully loaded package.
A plugin is compatible when its required contracts and behavior match the host environment in which it operates. Successful package installation or assembly loading tests only part of that relationship.
The current server release, plugin package and documented extension interfaces establish the actual target.
Several layers can disagree
| Layer | Compatibility question |
|---|---|
| Host API | Are the required interfaces and members available? |
| Runtime | Can this assembly and its dependencies execute here? |
| Native assets | Do architecture and operating-system ABI match? |
| Behavior | Does the extension handle the operation's current semantics? |
| Persistent state | Can it interpret existing configuration and stored data? |
| External services | Do its integrations still use a supported contract? |
A package can load while one later feature fails on a missing native library. Another can load and invoke successfully while misinterpreting a changed result field.
The development documentation contains examples for particular runtime targets. Those examples should not be treated as a timeless list of the runtime versions in every installed Emby release.
Loading is one checkpoint
An original compatibility scenario is:
Host H2 loads plugin P1.
P1 starts its ordinary configuration path.
Later operation requires interface member M2.
P1's selected dependency does not provide the required contract.
Startup success did not establish that later operation.
The labels describe a model rather than real Emby version numbers. Tests should exercise the feature and data path the plugin actually needs.
A source-code rebuild can resolve an API mismatch while still leaving behavior or migration work. Conversely, preserving one binary does not prove semantic compatibility after a host update.
Stored data have their own version relationship
An updated plugin may migrate its configuration. Returning to an older assembly may not reverse that migration or make the resulting state readable by the old code.
Backups and supported upgrade/downgrade paths therefore belong to the data lifecycle as well as the software lifecycle.
For Emby plugin use or development, record the actual host/package combination and the failed feature. The current plugin-development documentation supplies the extension contracts; a generic “DLL loads” observation does not establish the whole result.