From 376ab32e4ebd13a8c60b9a3597e9e8473bc43384 Mon Sep 17 00:00:00 2001 From: Petar Kirov Date: Wed, 12 Feb 2025 22:47:51 +0200 Subject: [PATCH] docs(sips/006-spin-plugins): Fix typo in `package.os` field definition (`osx` -> `macos`) At the time of writing (Spin v3.1.2), the `Os` enum is [defined][0] as follows: ```rs enum Os { Linux, Macos, Windows, } ``` This commit adjust the SIP to match the implementation by renaming `osx` to `macos`. Note that the SIP later on uses `macos` as part of the URL in one of the examples. [0]: https://github.com/fermyon/spin/blob/v3.1.2/crates/plugins/src/manifest.rs#L113 Signed-off-by: Petar Kirov --- docs/content/sips/006-spin-plugins.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/sips/006-spin-plugins.md b/docs/content/sips/006-spin-plugins.md index 4c29906a21..a881422371 100644 --- a/docs/content/sips/006-spin-plugins.md +++ b/docs/content/sips/006-spin-plugins.md @@ -159,7 +159,7 @@ A Spin plugin is defined by a Spin Plugin Manifest which is a JSON file that con "type": "string", "enum": [ "linux", - "osx", + "macos", "windows" ] }, @@ -227,4 +227,4 @@ While for now plugins are assumed to be executables, in the future, support for The proposed method of using version strings to declare compatibility between a plugin and Spin has several drawbacks. Firstly, this requires plugin creators to stay involved with their contribution, regularly testing and updating the compatibility of their plugin with Spin. One way to make this more hands-off would be to encourage plugin creators to also contribute an integration test. For each new spin release, a workflow in the plugins repository can automatically run these integration tests and bump compatibility versioning on success. This is a strategy taken by [MicroK8s](https://microk8s.io/docs/addons) for its core and community add-ons. -Another issue with using versioning to check for compatibility with Spin is that canary releases of Spin have the same version as the latest release. This means that if a user is using main or canary Spin, when Spin checks its version before installing a plugin, it may incorrectly assume compatibility even though its feature set is beyond that of the latest stable release. Spin templates currently have a workaround for detecting and handling this inconsistency. A more ideal way of assessing compatibility would be via capability checking wherein a plugin could declare what set of features it is compatible with and Spin would assert if those exist. For example, a plugin could be compatible with only a specific version of Spin manifests or only have support for WAGI. While a system like this would be full-proof, it would require deep design. As plugins are developed, a better understanding will come of what capabilities plugins need from Spin. From this, compatibility via compatibilities system could be designed. \ No newline at end of file +Another issue with using versioning to check for compatibility with Spin is that canary releases of Spin have the same version as the latest release. This means that if a user is using main or canary Spin, when Spin checks its version before installing a plugin, it may incorrectly assume compatibility even though its feature set is beyond that of the latest stable release. Spin templates currently have a workaround for detecting and handling this inconsistency. A more ideal way of assessing compatibility would be via capability checking wherein a plugin could declare what set of features it is compatible with and Spin would assert if those exist. For example, a plugin could be compatible with only a specific version of Spin manifests or only have support for WAGI. While a system like this would be full-proof, it would require deep design. As plugins are developed, a better understanding will come of what capabilities plugins need from Spin. From this, compatibility via compatibilities system could be designed.