chore(*): more spinframework org/url updates

Signed-off-by: Vaughn Dice <vaughn.dice@fermyon.com>

Author: vdice

Cargo.toml

@@ -7,11 +7,11 @@ license = { workspace = true }
 
 [workspace.package]
 version = "3.3.0-pre0"
-authors = ["Fermyon Engineering <engineering@fermyon.com>"]
+authors = ["Spin Framework Contributors"]
 edition = "2021"
 license = "Apache-2.0 WITH LLVM-exception"
-homepage = "https://developer.fermyon.com/spin"
-repository = "https://github.com/fermyon/spin"
+homepage = "https://spinframework.dev"
+repository = "https://github.com/spinframework/spin"
 rust-version = "1.81"
 
 [dependencies]

GOVERNANCE.md

@@ -5,23 +5,23 @@ This document describes the governance of the Spin project.
 The Spin project consists of several codebases with different release cycles. These codebases include:
 
 - Core Spin:
-    - [Spin](https://github.com/fermyon/spin)
+    - [Spin](https://github.com/spinframework/spin)
 - SDKs:
-    - [Spin Python SDK](https://github.com/fermyon/spin-python-sdk)
-    - [Spin JavaScript SDK](https://github.com/fermyon/spin-js-sdk)
-    - [Spin Rust SDK](https://github.com/fermyon/spin-rust-sdk)
-    - [Spin .NET SDK](https://github.com/fermyon/spin-dotnet-sdk)
-    - [Spin Go SDK](https://github.com/fermyon/spin-go-sdk)
+    - [Spin Python SDK](https://github.com/spinframework/spin-python-sdk)
+    - [Spin JavaScript SDK](https://github.com/spinframework/spin-js-sdk)
+    - [Spin Rust SDK](https://github.com/spinframework/spin-rust-sdk)
+    - [Spin .NET SDK](https://github.com/spinframework/spin-dotnet-sdk)
+    - [Spin Go SDK](https://github.com/spinframework/spin-go-sdk)
 - Plugins:
-    - [Spin Plugins Index Repository](https://github.com/fermyon/spin-plugins)
+    - [Spin Plugins Index Repository](https://github.com/spinframework/spin-plugins)
     - [Fermyon Platform Plugin](https://github.com/fermyon/platform-plugin)
-    - [Spin Test Plugin](https://github.com/fermyon/spin-test)
+    - [Spin Test Plugin](https://github.com/spinframework/spin-test)
 - Triggers:
-    - [Spin Command Trigger](https://github.com/fermyon/spin-trigger-command)
-    - [Spin SQS Trigger](https://github.com/fermyon/spin-trigger-sqs)
-    - [Spin Cron Trigger](https://github.com/fermyon/spin-trigger-cron)
+    - [Spin Command Trigger](https://github.com/spinframework/spin-trigger-command)
+    - [Spin SQS Trigger](https://github.com/spinframework/spin-trigger-sqs)
+    - [Spin Cron Trigger](https://github.com/spinframework/spin-trigger-cron)
 - Other
-    - [Spin Fileserver](https://github.com/fermyon/spin-fileserver)
+    - [Spin Fileserver](https://github.com/spinframework/spin-fileserver)
 
 Each repository is subject to the same overall governance model, but has different teams of people (“maintainers”) with permissions and access to the repository. This is meant to increase diversity of maintainers in the Spin project and also increases the velocity of code changes. Major changes and features to the project including additions to the repository list above are to be proposed through the [Spin Improvement Proposal](docs/content/sips/index.md) process.
 
@@ -39,11 +39,11 @@ Changes to project maintainers use the following:
 - Project maintainers MUST remain active on the project. If they are unresponsive for > 3 months, they will lose project maintainer-ship, unless the remaining project maintainers of the given project and the Spin Governance Committee agree to extend the period to be greater than 3 months.
 - New maintainers MUST be nominated by existing maintainers. Maintainers are to discuss and agree in a private setting adding a new maintainer. Once a decision has been made, a maintainer may be added to the project via a pull request to the relevant MAINTAINERS.md file.
 - A maintainer may be removed for a [code of conduct](CODE_OF_CONDUCT.md) violation by the Spin Governance Committee. Code of conduct violations may be submitted to any member(s) on the Spin Governance Committee by email. See email information on MAINTAINERS.md.
-- When a project has no active maintainers, the maintainers of the [fermyon/spin Github repo](https://github.com/fermyon/spin) become responsible for it, and may archive the project, or find new maintainers.
+- When a project has no active maintainers, the maintainers of the [spinframework/spin Github repo](https://github.com/spinframework/spin) become responsible for it, and may archive the project, or find new maintainers.
 
 ## Spin Governance Committee
 
-The project maintainers for [github.com/fermyon/spin](http://github.com/fermyon/spin) also serve as the Spin Governance Committee and have the following additional responsibilities:
+The project maintainers for [github.com/spinframework/spin](https://github.com/spinframework/spin) also serve as the Spin Governance Committee and have the following additional responsibilities:
 
 - Maintaining the mission, vision, values, and scope of the project
 - Refining this governance document

ROADMAP.md

@@ -6,12 +6,12 @@ Taking these considerations into account and feedback from the community, the Sp
 
 1. Composition and polyglot development experience
 
-   WebAssembly components unlock a new opportunity as it relates to the polyglot development experience. In Spin, we seek to enable the polyglot re-use of components, allowing developers to specify how to use components written in various languages as libraries to fulfill dependencies in their Spin components as specified in the [Component Dependencies SIP](https://github.com/fermyon/spin/pull/2543). We’ll use this as the foundational work to then iterate on the polyglot development experience.
+   WebAssembly components unlock a new opportunity as it relates to the polyglot development experience. In Spin, we seek to enable the polyglot re-use of components, allowing developers to specify how to use components written in various languages as libraries to fulfill dependencies in their Spin components as specified in the [Component Dependencies SIP](https://github.com/spinframework/spin/pull/2543). We’ll use this as the foundational work to then iterate on the polyglot development experience.
 
 2. Building a composable runtime
 
-   There are currently some assumptions baked into the Spin runtime about the functionality provided by underlying host environments, however it’s likely a host environment may offer a subset of the capabilities assumed in the Spin runtime today or an entirely custom set of capabilities. Modularizing the Spin runtime allows it to be more readily extendable and customizable based on host environment. This requires breaking changes and a major code refactor, so this work will also be the basis for a Spin 3.0 release. See the [Spin Factors SIP](https://github.com/fermyon/spin/pull/2518) for an overview.
+   There are currently some assumptions baked into the Spin runtime about the functionality provided by underlying host environments, however it’s likely a host environment may offer a subset of the capabilities assumed in the Spin runtime today or an entirely custom set of capabilities. Modularizing the Spin runtime allows it to be more readily extendable and customizable based on host environment. This requires breaking changes and a major code refactor, so this work will also be the basis for a Spin 3.0 release. See the [Spin Factors SIP](https://github.com/spinframework/spin/pull/2518) for an overview.
 
 3. Spin application development experience improvements
 
-   It has become increasingly clear that there is interest in scenarios where Spin is used as a developer tool to build applications that target runtimes other than the Spin runtime (example: [NGINX Unit](https://unit.nginx.org/news/2024/fermyon-spin-rust-sdk/)). Right now, there are implicit assumptions made about the target environment both by the Spin CLI and the Spin SDKs. To support these scenarios, there will need to be work done around modularizing SDKs and building tooling that validates a Spin application can be run with a specific target environment. Foundational work for these efforts is described in the [Spin Build Target Check SIP](https://github.com/fermyon/spin/pull/2556) and is an ongoing effort.
+   It has become increasingly clear that there is interest in scenarios where Spin is used as a developer tool to build applications that target runtimes other than the Spin runtime (example: [NGINX Unit](https://unit.nginx.org/news/2024/fermyon-spin-rust-sdk/)). Right now, there are implicit assumptions made about the target environment both by the Spin CLI and the Spin SDKs. To support these scenarios, there will need to be work done around modularizing SDKs and building tooling that validates a Spin application can be run with a specific target environment. Foundational work for these efforts is described in the [Spin Build Target Check SIP](https://github.com/spinframework/spin/pull/2556) and is an ongoing effort.

crates/componentize/src/bugs.rs

@@ -45,7 +45,7 @@ impl std::fmt::Display for WasiLibc377Bug {
             f,
             "This Wasm module appears to have been compiled with wasi-sdk version <19 \
             which contains a critical memory safety bug. For more information, see: \
-            https://github.com/fermyon/spin/issues/2552"
+            https://github.com/spinframework/spin/issues/2552"
         )
     }
 }

crates/core/src/lib.rs

@@ -78,7 +78,7 @@ impl Default for Config {
         inner.epoch_interruption(true);
         inner.wasm_component_model(true);
         // If targeting musl, disable native unwind to address this issue:
-        // https://github.com/fermyon/spin/issues/2889
+        // https://github.com/spinframework/spin/issues/2889
         // TODO: remove this when wasmtime is updated to >= v27.0.0
         #[cfg(all(target_os = "linux", target_env = "musl"))]
         inner.native_unwind_info(false);

crates/plugins/src/lookup.rs

@@ -13,7 +13,7 @@ const PLUGINS_REPO_LOCAL_DIRECTORY: &str = ".spin-plugins";
 // Name of directory containing the installed manifests
 pub(crate) const PLUGINS_REPO_MANIFESTS_DIRECTORY: &str = "manifests";
 
-pub(crate) const SPIN_PLUGINS_REPO: &str = "https://github.com/fermyon/spin-plugins/";
+pub(crate) const SPIN_PLUGINS_REPO: &str = "https://github.com/spinframework/spin-plugins/";
 
 /// Looks up plugin manifests in centralized spin plugin repository.
 pub struct PluginLookup {

crates/plugins/src/manifest.rs

@@ -9,7 +9,7 @@ use crate::PluginStore;
 
 /// Expected schema of a plugin manifest. Should match the latest Spin plugin
 /// manifest JSON schema:
-/// <https://github.com/fermyon/spin-plugins/tree/main/json-schema>
+/// <https://github.com/spinframework/spin-plugins/tree/main/json-schema>
 #[derive(Serialize, Debug, Deserialize, PartialEq)]
 #[serde(rename_all = "camelCase")]
 pub struct PluginManifest {

crates/trigger-http/src/spin.rs

@@ -61,7 +61,7 @@ impl HttpExecutor for SpinHttpExecutor {
 
         // Preparing to remove the params field. We are leaving it in place for now
         // to avoid breaking the ABI, but no longer pass or accept values in it.
-        // https://github.com/fermyon/spin/issues/663
+        // https://github.com/spinframework/spin/issues/663
         let params = vec![];
 
         let uri = match parts.uri.path_and_query() {

cross/Dockerfile

@@ -1,6 +1,6 @@
 FROM ghcr.io/cross-rs/aarch64-unknown-linux-musl@sha256:7ad32efcae37c178fed63da301ff982d2430f15fc7d39e6c0b28124e14fac394
 
-## as per analysis done in https://github.com/fermyon/spin/pull/2287#issuecomment-1970145410 we need
+## as per analysis done in https://github.com/spinframework/spin/pull/2287#issuecomment-1970145410 we need
 ## to disable the cmake config in cross-rs. Setting CROSS_SYSROOT=/ seems to have done the trick
 
 ENV CROSS_SYSROOT=/

cross/README.md

@@ -5,4 +5,4 @@ These intrinsics are missing for `aarch64` in `gcc < 10.3`, while `cross-rs` shi
 
 The code in this folder does a feature check and patches the `arm_neon.h` header with polyfills if the functions are missing.
 
-See https://github.com/fermyon/spin/issues/1786 for the upstream issue.
+See https://github.com/spinframework/spin/issues/1786 for the upstream issue.