28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
# Plugin manifests declare Plugin SDK compatibility
|
|
|
|
The historical `block_core` compatibility field predates the standalone
|
|
Plugin SDK and is ambiguous: CMS core and the plugin-facing SDK have separate
|
|
release cycles. Interpreting the same constraint against both versions can
|
|
select an artifact that the host cannot load or reject one that is compatible.
|
|
|
|
Decision: `[compatibility]` gains an optional `plugin_sdk` string containing a
|
|
semantic-version constraint for the plugin-facing SDK/ABI, for example
|
|
`plugin_sdk = ">=0.3.7"`. Manifest parsing preserves the value verbatim;
|
|
registry and host resolvers own constraint validation and matching.
|
|
|
|
An omitted or empty value is undeclared compatibility, not a wildcard.
|
|
Automated resolution against a host SDK version must fail closed, except for
|
|
an explicitly bounded migration policy for releases published before this
|
|
field existed. `block_core` remains a separate historical constraint and is
|
|
not reinterpreted as the CMS application's own version.
|
|
|
|
Consequences:
|
|
|
|
- Plugins can state the actual SDK/ABI range they require.
|
|
- CMS core can evolve independently of the public Plugin SDK.
|
|
- New releases must declare `plugin_sdk` to participate in automatic
|
|
SDK-compatible selection.
|
|
|
|
Keywords: plugin.mod, compatibility, plugin_sdk, PluginSDK, ABI, semantic
|
|
version, plugin resolver, fail closed
|