Removes duplicate latest version

README.md

@@ -3,6 +3,7 @@
 This repo contains the Upbound documentation built with Docusaurus. 
 
 * [Local Development](#local-development)
+* [Self-Hosted Spaces versioning](#self-hosted-spaces-versioning)
 * [Style Guide](#style-guide)
 * [Code style guide](#code-style-guide)
 * [Markdown](#markdown)
@@ -84,6 +85,74 @@ common errors.
 | `make help` | Display all available commands |
 
 
+## Self-Hosted Spaces versioning
+
+The Self-Hosted Spaces docs are the only versioned plugin in this repo. UXP,
+Cloud Spaces, and the rest are unversioned.
+
+### Layout
+
+- `self-hosted-spaces-docs/` — the live latest version. Served at
+  `/self-hosted-spaces/`.
+- `self-hosted-spaces_versioned_docs/version-X.Y/` — frozen snapshots of past
+  versions. Served at `/self-hosted-spaces/X.Y/`.
+- `self-hosted-spaces_versioned_sidebars/version-X.Y-sidebars.json` — sidebar
+  config for each frozen version.
+- `self-hosted-spaces_versions.json` — the list of frozen versions, newest
+  first. Does **not** include the live latest.
+
+The label for the live latest is set in two places (keep them in sync):
+
+- `versions.current.label` in `docusaurus.config.js`
+- `LATEST_VERSION` in `src/theme/DocSidebar/Desktop/Content/index.js`
+
+### Patching docs
+
+- **Live latest** — edit files in `self-hosted-spaces-docs/`. Changes go live at
+  `/self-hosted-spaces/...` on the next deploy.
+- **An older version** — edit files in
+  `self-hosted-spaces_versioned_docs/version-X.Y/`. Older versions don't
+  inherit edits from the live latest. If a fix applies to multiple versions,
+  apply it to each tree.
+
+### Cutting a new version
+
+When shipping a new version, you snapshot the *current* state under the label
+it currently represents, then bump the label for the next cycle. For example,
+shipping 1.17 when the live latest is labeled 1.16:
+
+1. Make sure `self-hosted-spaces-docs/` reflects the final state of 1.16.
+2. Snapshot current as 1.16:
+
+   ```bash
+   npm run docusaurus -- docs:version:self-hosted-spaces 1.16
+   ```
+
+   This copies `self-hosted-spaces-docs/` to
+   `self-hosted-spaces_versioned_docs/version-1.16/`, generates
+   `self-hosted-spaces_versioned_sidebars/version-1.16-sidebars.json` from the
+   current sidebar, and prepends `"1.16"` to `self-hosted-spaces_versions.json`.
+
+3. Bump the live-latest label in both places:
+
+   - `versions.current.label` in `docusaurus.config.js` → `"1.17"`
+   - `LATEST_VERSION` in `src/theme/DocSidebar/Desktop/Content/index.js` →
+     `'1.17'`
+
+4. Apply 1.17 content changes to `self-hosted-spaces-docs/`.
+5. Run `npm run clear && npm start` to verify the dropdown shows
+   `1.17 (Latest)` and `/self-hosted-spaces/1.16/` resolves to the new
+   snapshot.
+6. Commit and open a PR.
+
+### Dropping an old version
+
+To stop publishing (for example) 1.13:
+
+1. Delete `self-hosted-spaces_versioned_docs/version-1.13/`.
+2. Delete `self-hosted-spaces_versioned_sidebars/version-1.13-sidebars.json`.
+3. Remove `"1.13"` from `self-hosted-spaces_versions.json`.
+
 ## Style guide
 
 **TL;DR**

docusaurus.config.js

@@ -95,6 +95,12 @@ const config = {
                 routeBasePath: "/self-hosted-spaces",
                 sidebarPath: require.resolve("./src/sidebars/self-hosted-spaces.js"),
                 includeCurrentVersion: true,
+                lastVersion: "current",
+                versions: {
+                    current: {
+                        label: "1.16",
+                    },
+                },
             },
         ],
         [

self-hosted-spaces-docs/howtos/automation-and-gitops/overview.md

@@ -38,13 +38,13 @@ The way you configure GitOps depends on your deployment model:
 
 **Choose your path based on your deployment model:**
 
-###. Cloud Spaces
+### Cloud Spaces
 If you're using Upbound Cloud Spaces (Dedicated or Managed):
 1. Start with [GitOps with Upbound Control Planes](/cloud-spaces/howtos/gitops-on-upbound/)
 2. Learn how to integrate Argo CD with Cloud Spaces
 3. Manage both control plane infrastructure and Upbound resources declaratively
 
-###. Self-Hosted Spaces
+### Self-Hosted Spaces
 If you're running self-hosted Spaces:
 1. Start with [GitOps with ArgoCD in Self-Hosted Spaces](../gitops.md)
 2. Learn how to configure control plane connection secrets

self-hosted-spaces-docs/howtos/scaling-resources.md

@@ -157,7 +157,7 @@ controlPlanes:
         cpu: "500m"
         memory: "512Mi"
   ha:
-    enabled: true  #. production environments
+    enabled: true  # For production environments
 ```
 
 Apply the configuration using Helm:

self-hosted-spaces-docs/howtos/space-observability.md

@@ -88,7 +88,7 @@ logs, and traces to your configured observability backends.
 This feature requires the [OpenTelemetry Operator][opentelemetry-operator] on
 the Space cluster.
 
-Note: If running Spaces v1.11 or later, use OpenTelemetry Operator v0.110.0 or
+Note: If running Spaces v1.16 or later, use OpenTelemetry Operator v0.139.0 or
 later due to breaking changes in the OpenTelemetry Operator.
 
 ## Configuration

self-hosted-spaces_versioned_docs/version-1.13/howtos/automation-and-gitops/overview.md

@@ -38,13 +38,13 @@ The way you configure GitOps depends on your deployment model:
 
 **Choose your path based on your deployment model:**
 
-###. Cloud Spaces
+### Cloud Spaces
 If you're using Upbound Cloud Spaces (Dedicated or Managed):
 1. Start with [GitOps with Upbound Control Planes](/cloud-spaces/howtos/gitops-on-upbound/)
 2. Learn how to integrate Argo CD with Cloud Spaces
 3. Manage both control plane infrastructure and Upbound resources declaratively
 
-###. Self-Hosted Spaces
+### Self-Hosted Spaces
 If you're running self-hosted Spaces:
 1. Start with [GitOps with ArgoCD in Self-Hosted Spaces](../gitops-with-argocd.md)
 2. Learn how to configure control plane connection secrets

self-hosted-spaces_versioned_docs/version-1.13/howtos/scaling-resources.md

@@ -78,8 +78,8 @@ controlPlanes:
 
 For AWS:
 - Use GP3 volumes with adequate IOPS
--. AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
--. optimal performance, provision at least 32Gi to support up to 16,000 IOPS
+- For AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
+- For optimal performance, provision at least 32Gi to support up to 16,000 IOPS
 
 For GCP and Azure:
 - Use SSD-based persistent disk types for optimal performance
@@ -157,7 +157,7 @@ controlPlanes:
         cpu: "500m"
         memory: "512Mi"
   ha:
-    enabled: true  #. production environments
+    enabled: true  # For production environments
 ```
 
 Apply the configuration using Helm:

self-hosted-spaces_versioned_docs/version-1.14/howtos/automation-and-gitops/overview.md

@@ -38,13 +38,13 @@ The way you configure GitOps depends on your deployment model:
 
 **Choose your path based on your deployment model:**
 
-###. Cloud Spaces
+### Cloud Spaces
 If you're using Upbound Cloud Spaces (Dedicated or Managed):
 1. Start with [GitOps with Upbound Control Planes](/cloud-spaces/howtos/gitops-on-upbound/)
 2. Learn how to integrate Argo CD with Cloud Spaces
 3. Manage both control plane infrastructure and Upbound resources declaratively
 
-###. Self-Hosted Spaces
+### Self-Hosted Spaces
 If you're running self-hosted Spaces:
 1. Start with [GitOps with ArgoCD in Self-Hosted Spaces](../gitops-with-argocd.md)
 2. Learn how to configure control plane connection secrets

self-hosted-spaces_versioned_docs/version-1.14/howtos/scaling-resources.md

@@ -78,8 +78,8 @@ controlPlanes:
 
 For AWS:
 - Use GP3 volumes with adequate IOPS
--. AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
--. optimal performance, provision at least 32Gi to support up to 16,000 IOPS
+- For AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
+- For optimal performance, provision at least 32Gi to support up to 16,000 IOPS
 
 For GCP and Azure:
 - Use SSD-based persistent disk types for optimal performance
@@ -157,7 +157,7 @@ controlPlanes:
         cpu: "500m"
         memory: "512Mi"
   ha:
-    enabled: true  #. production environments
+    enabled: true  # For production environments
 ```
 
 Apply the configuration using Helm:

self-hosted-spaces_versioned_docs/version-1.15/howtos/automation-and-gitops/overview.md

@@ -38,13 +38,13 @@ The way you configure GitOps depends on your deployment model:
 
 **Choose your path based on your deployment model:**
 
-###. Cloud Spaces
+### Cloud Spaces
 If you're using Upbound Cloud Spaces (Dedicated or Managed):
 1. Start with [GitOps with Upbound Control Planes](/cloud-spaces/howtos/gitops-on-upbound/)
 2. Learn how to integrate Argo CD with Cloud Spaces
 3. Manage both control plane infrastructure and Upbound resources declaratively
 
-###. Self-Hosted Spaces
+### Self-Hosted Spaces
 If you're running self-hosted Spaces:
 1. Start with [GitOps with ArgoCD in Self-Hosted Spaces](../gitops-with-argocd.md)
 2. Learn how to configure control plane connection secrets

self-hosted-spaces_versioned_docs/version-1.15/howtos/scaling-resources.md

@@ -78,8 +78,8 @@ controlPlanes:
 
 For AWS:
 - Use GP3 volumes with adequate IOPS
--. AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
--. optimal performance, provision at least 32Gi to support up to 16,000 IOPS
+- For AWS GP3 volumes, IOPS scale with volume size (3000 IOPS baseline)
+- For optimal performance, provision at least 32Gi to support up to 16,000 IOPS
 
 For GCP and Azure:
 - Use SSD-based persistent disk types for optimal performance
@@ -157,7 +157,7 @@ controlPlanes:
         cpu: "500m"
         memory: "512Mi"
   ha:
-    enabled: true  #. production environments
+    enabled: true  # For production environments
 ```
 
 Apply the configuration using Helm:

self-hosted-spaces_versioned_docs/version-1.15/howtos/space-observability.md

@@ -173,7 +173,7 @@ The sampling behavior depends on whether a parent trace context exists:
 
 - **With parent context**: If a `traceparent` header is present, the parent's
   sampling decision is respected, enabling proper distributed tracing across services.
-- **Root spans**:. new traces without a parent, Envoy samples based on
+- **Root spans**: For new traces without a parent, Envoy samples based on
   `x-request-id` hashing. The default sampling rate is 10%.
 
 #### TLS configuration for external collectors