Drop v1alpha2 from URL structure

This change drops the "v1alpha2" file from the documentation site, which
will result in it being dropped from the URLs.

Symlinks have been put in place to ensure that old-style URLs are still
served.

hack/make-docs.sh

@@ -37,4 +37,5 @@ mkdocs build
 # Generate v1alpha2 API docs
 ./hack/api-docs/generate.sh site/spec.html
 # Add them to spec page originally generated by mkdocs
+run::sed -e '/REPLACE_WITH_GENERATED_CONTENT/{r site/spec.html' -e 'd;}' site/references/spec/index.html
 run::sed -e '/REPLACE_WITH_GENERATED_CONTENT/{r site/spec.html' -e 'd;}' site/v1alpha2/references/spec/index.html

mkdocs.yml

@@ -43,22 +43,22 @@ nav:
     - Implementations: implementations.md
     - FAQ: faq.md
   - Guides:
-    - Getting started: v1alpha2/guides/getting-started.md
-    - Simple Gateway: v1alpha2/guides/simple-gateway.md
-    - HTTP routing: v1alpha2/guides/http-routing.md
-    - HTTP redirects and rewrites: v1alpha2/guides/http-redirect-rewrite.md
-    - HTTP traffic splitting: v1alpha2/guides/traffic-splitting.md
-    - Cross-Namespace routing: v1alpha2/guides/multiple-ns.md
-    - TLS: v1alpha2/guides/tls.md
-    - TCP routing: v1alpha2/guides/tcp.md
+    - Getting started: guides/getting-started.md
+    - Simple Gateway: guides/simple-gateway.md
+    - HTTP routing: guides/http-routing.md
+    - HTTP redirects and rewrites: guides/http-redirect-rewrite.md
+    - HTTP traffic splitting: guides/traffic-splitting.md
+    - Cross-Namespace routing: guides/multiple-ns.md
+    - TLS: guides/tls.md
+    - TCP routing: guides/tcp.md
   - Reference:
     - API Types:
-        GatewayClass: v1alpha2/api-types/gatewayclass.md
-        Gateway: v1alpha2/api-types/gateway.md
-        HTTPRoute: v1alpha2/api-types/httproute.md
-        ReferenceGrant: v1alpha2/api-types/referencegrant.md
-    - API specification: v1alpha2/references/spec.md
-    - Policy Attachment: v1alpha2/references/policy-attachment.md
+        GatewayClass: api-types/gatewayclass.md
+        Gateway: api-types/gateway.md
+        HTTPRoute: api-types/httproute.md
+        ReferenceGrant: api-types/referencegrant.md
+    - API specification: references/spec.md
+    - Policy Attachment: references/policy-attachment.md
     - Enhancement Proposals:
       - Overview: contributing/gep.md
       - ... | geps/gep-*.md

site-src/v1alpha2/api-types/httproute.md → site-src/api-types/httproute.md

@@ -17,7 +17,7 @@ The specification of an HTTPRoute consists of:
   fields.
 
 The following illustrates an HTTPRoute that sends all traffic to one Service:
-![httproute-basic-example](/v1alpha2/images/httproute-basic-example.svg)
+![httproute-basic-example](/images/httproute-basic-example.svg)
 
 ### Attaching to Gateways
 
@@ -197,12 +197,12 @@ only one Route rule may match each request. For more information on how conflict
 resolution applies to merging, refer to the [API specification][httprouterule].
 
 
-[httproute]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute
-[httprouterule]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule
-[hostname]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Hostname
+[httproute]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute
+[httprouterule]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule
+[hostname]: /references/spec/#gateway.networking.k8s.io/v1alpha2.Hostname
 [rfc-3986]: https://tools.ietf.org/html/rfc3986
-[matches]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteMatch
-[filters]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteFilter
-[backendRef]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPBackendRef
-[parentRef]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ParentRef
+[matches]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteMatch
+[filters]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteFilter
+[backendRef]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPBackendRef
+[parentRef]: /references/spec/#gateway.networking.k8s.io/v1alpha2.ParentRef
 

site-src/v1alpha2/api-types/referencegrant.md → site-src/api-types/referencegrant.md

@@ -14,7 +14,7 @@ A ReferenceGrant can be used to enable cross namespace references within
 Gateway API. In particular, Routes may forward traffic to backends in other
 namespaces, or Gateways may refer to Secrets in another namespace.
 
-![Reference Grant](/v1alpha2/images/referencegrant-simple.png)
+![Reference Grant](/images/referencegrant-simple.png)
 
 In the past, we've seen that forwarding traffic across namespace boundaries is a
 desired feature, but without a safeguard like ReferenceGrant,
@@ -87,7 +87,7 @@ While the API is simplistic in nature, it comes with a few notable decisions:
    other. This makes it impossible for them to conflict with each other.
 
 Please see the [API
-Specification](/v1alpha2/references/spec#gateway.networking.k8s.io/v1alpha2.ReferenceGrant)
+Specification](/references/spec#gateway.networking.k8s.io/v1alpha2.ReferenceGrant)
 for more details on how specific ReferenceGrant fields are interpreted.
 
 ## Exceptions

site-src/blog/2021/introducing-v1alpha2.md

@@ -104,7 +104,7 @@ This is intended to allow things like:
 As a simple example, a TimeoutPolicy may be attached to a Gateway. The effects
 of that policy would cascade down to Routes attached to that policy:
 
-![Simple Ingress Example](/v1alpha2/images/policy/ingress-simple.png)
+![Simple Ingress Example](/images/policy/ingress-simple.png)
 
 This is covered in more detail in [GEP 713](https://gateway-api.sigs.k8s.io/geps/gep-713/).
 

site-src/concepts/api-overview.md

@@ -285,7 +285,7 @@ reverse proxy is:
 
 TLS is configured on Gateway listeners, and may be referred to across namespaces.
 
-Please refer to the [TLS details](/v1alpha2/guides/tls) guide for a deep dive on TLS.
+Please refer to the [TLS details](/guides/tls) guide for a deep dive on TLS.
 
 
 ## Extension points

site-src/concepts/security-model.md

@@ -122,7 +122,7 @@ the ReferenceGrant.
 ```
 
 For more information on ReferenceGrant, refer to our [detailed documentation
-for this resource](/v1alpha2/api-types/referencegrant.md).
+for this resource](/api-types/referencegrant.md).
 
 ## Advanced Concept: Limiting Namespaces Where a GatewayClass Can Be Used
 Some infrastructure providers or cluster operators may wish to limit the

site-src/v1alpha2/guides/getting-started.md → site-src/guides/getting-started.md

@@ -7,13 +7,13 @@ _THEN_
 
 **2.**   **Try out one of the available guides:**
 
-- [Simple Gateway](/v1alpha2/guides/simple-gateway) (a good one to start out with)
-- [HTTP routing](/v1alpha2/guides/http-routing)
-- [HTTP redirects and rewrites](/v1alpha2/guides/http-redirect-rewrite)
-- [HTTP traffic splitting](/v1alpha2/guides/traffic-splitting)
-- [Routing across Namespaces](/v1alpha2/guides/multiple-ns)
-- [Configuring TLS](/v1alpha2/guides/tls)
-- [TCP routing](/v1alpha2/guides/tcp)
+- [Simple Gateway](/guides/simple-gateway) (a good one to start out with)
+- [HTTP routing](/guides/http-routing)
+- [HTTP redirects and rewrites](/guides/http-redirect-rewrite)
+- [HTTP traffic splitting](/guides/traffic-splitting)
+- [Routing across Namespaces](/guides/multiple-ns)
+- [Configuring TLS](/guides/tls)
+- [TCP routing](/guides/tcp)
 
 ## Installing a Gateway controller
 

site-src/v1alpha2/guides/http-redirect-rewrite.md → site-src/guides/http-redirect-rewrite.md

@@ -1,8 +1,8 @@
 # HTTP path redirects and rewrites
 
-[HTTPRoute resources](/v1alpha2/api-types/httproute) can issue redirects to
+[HTTPRoute resources](/api-types/httproute) can issue redirects to
 clients or rewrite paths sent upstream using
-[filters](/v1alpha2/api-types/httproute#filters-optional). This guide shows how
+[filters](/api-types/httproute#filters-optional). This guide shows how
 to use these features.
 
 Note that redirect and rewrite filters are mutually incompatible. Rules cannot
@@ -12,7 +12,7 @@ use both filter types at once.
 
 Redirects return HTTP 3XX responses to a client, instructing it to retrive a
 different resource. [`RequestRedirect` rule
-filters](v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRequestRedirectFilter)
+filters](/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRequestRedirectFilter)
 instruct Gateways to emit a redirect response to requests matching a filtered
 HTTPRoute rule.
 
@@ -73,7 +73,7 @@ https://redirect.example/paprika/teaspoon` response headers.
 
 Rewrites modify components of a client request before proxying it upstream. A
 [`URLRewrite`
-filter](/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPURLRewriteFilter)
+filter](/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPURLRewriteFilter)
 can change the upstream request hostname and/or path. For example, the
 following HTTPRoute will accept a request for
 `https://rewrite.example/cardamom` and send it upstream to `example-svc` with

site-src/v1alpha2/guides/http-routing.md → site-src/guides/http-routing.md

@@ -1,6 +1,6 @@
 # HTTP routing
 
-The [HTTPRoute resource](/v1alpha2/api-types/httproute) allows you to match on HTTP traffic and
+The [HTTPRoute resource](/api-types/httproute) allows you to match on HTTP traffic and
 direct it to Kubernetes backends. This guide shows how the HTTPRoute matches
 traffic on host, header, and path fields and forwards it to different
 Kubernetes Services.
@@ -13,14 +13,14 @@ Services:
 to `bar-svc-canary`
 - Traffic to `bar.example.com/*` without the header is forwarded to `bar-svc`
 
-![HTTP Routing](/v1alpha2/images/http-routing.png)
+![HTTP Routing](/images/http-routing.png)
 
 The dotted lines show the Gateway resources deployed to configure this routing
 behavior. There are two HTTPRoute resources that create routing rules on the
 same `prod-web` Gateway. This illustrates how more than one Route can bind to a
 Gateway which allows Routes to merge on a Gateway as long as they don't
 conflict. For more information on Route merging, refer to the [HTTPRoute
-documentation](/v1alpha2/api-types/httproute#merging).
+documentation](/api-types/httproute#merging).
 
 In order to receive traffic from a [Gateway][gateway] an `HTTPRoute` resource
 must be configured with `ParentRefs` which reference the parent gateway(s) that it
@@ -57,6 +57,6 @@ missing or not `canary` then it'll be forwarded to `bar-svc`.
 {% include 'v1alpha2/http-routing/bar-httproute.yaml' %}
 ```
 
-[gateway]:https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteSpec
-[spec]:https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteSpec
+[gateway]: /references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway
+[spec]: /references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteSpec
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/

site-src/v1alpha2/guides/multiple-ns.md → site-src/guides/multiple-ns.md

@@ -36,7 +36,7 @@ to centrally control security without directly involving application teams.
 
 The logical relationship between the Gateway API resources looks like this:
 
-![Cross-Namespace routing](../images/cross-namespace-routing.svg)
+![Cross-Namespace routing](/images/cross-namespace-routing.svg)
 
 ## Cross-namespace Route Attachment
 
@@ -156,7 +156,7 @@ Gateway that these Routes want to attach to.
 
 After these three Routes are deployed, they will all be attached to the
 `shared-gateway` Gateway. The Gateway merges these Routes into a single flat
-list of routing rules. [Routing precedence](/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
+list of routing rules. [Routing precedence](/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
 between these routing rules is determined by most specific match and
 conflicts are handled according to [conflict
 resolution](/concepts/guidelines#conflicts). This provides predictable and

site-src/v1alpha2/guides/simple-gateway.md → site-src/guides/simple-gateway.md

@@ -6,7 +6,7 @@ deployed together by the same owner. This represents a similar kind of model
 used for Ingress. In this guide, a Gateway and HTTPRoute are deployed which
 match all HTTP traffic and directs it to a single Service named `foo-svc`. 
 
-![Simple Gateway](/v1alpha2/images/single-service-gateway.png)
+![Simple Gateway](/images/single-service-gateway.png)
 
 ```yaml  
 {% include 'v1alpha2/simple-gateway/gateway.yaml' %}

site-src/v1alpha2/guides/tls.md → site-src/guides/tls.md

@@ -12,7 +12,7 @@ effectively.
 
 ## Client/Server and TLS
 
-![overview](/v1alpha2/images/tls-overview.svg)
+![overview](/images/tls-overview.svg)
 
 For Gateways, there are two connections involved:
 

site-src/v1alpha2/guides/traffic-splitting.md → site-src/guides/traffic-splitting.md

@@ -1,6 +1,6 @@
 # HTTP traffic splitting
 
-The [HTTPRoute resource](/v1alpha2/api-types/httproute) allows you to specify 
+The [HTTPRoute resource](/api-types/httproute) allows you to specify 
 weights to shift traffic between different backends. This is useful for 
 splitting traffic during rollouts, canarying changes, or for emergencies. 
 The HTTPRoute`spec.rules.backendRefs` accepts a list of backends that a route 
@@ -9,7 +9,7 @@ the split of traffic between them. The following YAML snippet shows how two
 Services are listed as backends for a single route rule. This route rule 
 will split traffic 90% to `foo-v1` and 10% to `foo-v2`.
 
-![Traffic splitting](/v1alpha2/images/simple-split.png)
+![Traffic splitting](/images/simple-split.png)
 
 ```yaml
 {% include 'v1alpha2/traffic-splitting/simple-split.yaml' %}  
@@ -41,11 +41,11 @@ production user traffic for `foo.example.com`. The following HTTPRoute has no
 recieve 100% of the traffic matched by each of their route rules. A canary
 route rule is used (matching the header `traffic=test`) to send synthetic test
 traffic before splitting any production user traffic to `foo-v2`.
-[Routing precedence](/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
+[Routing precedence](/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
 ensures that all traffic with the matching host and header 
 (the most specific match) will be sent to `foo-v2`.
 
-![Traffic splitting](/v1alpha2/images/traffic-splitting-1.png)
+![Traffic splitting](/images/traffic-splitting-1.png)
 
 
 ```yaml
@@ -61,7 +61,7 @@ as a backend along with weights. The weights add up to a total of 100 so
 `foo-v1` recieves 90/100=90% of the traffic and `foo-v2` recieves
 10/100=10% of the traffic.
 
-![Traffic splitting](/v1alpha2/images/traffic-splitting-2.png)
+![Traffic splitting](/images/traffic-splitting-2.png)
 
 
 ```yaml
@@ -74,7 +74,7 @@ Finally, if all signals are positive, it is time to fully shift traffic to
 `foo-v2` and complete the rollout. The weight for `foo-v1` is set to
 `0` so that it is configured to accept zero traffic. 
 
-![Traffic splitting](/v1alpha2/images/traffic-splitting-3.png)
+![Traffic splitting](/images/traffic-splitting-3.png)
 
 
 ```yaml

site-src/index.md

@@ -19,9 +19,9 @@ interested in conforming to the API, the following resources will help give
 you the necessary background:
 
 - [API overview](/concepts/api-overview)
-- [User guides](/v1alpha2/guides/getting-started)
+- [User guides](/guides/getting-started)
 - [Gateway controller implementations](/implementations)
-- [API reference spec](/v1alpha2/references/spec)
+- [API reference spec](/references/spec)
 - [Community links](/contributing/community) and [developer guide](/contributing/devguide)
 
 
@@ -76,19 +76,19 @@ used by many different and non-coordinating teams, all bound by the policies
 and constraints set by cluster operators. The following example shows how this
 works in practice.
 
-A cluster operator creates a [Gateway](/v1alpha2/api-types/gateway) resource derived from a
-[GatewayClass](/v1alpha2/api-types/gatewayclass). This Gateway deploys or configures the
+A cluster operator creates a [Gateway](/api-types/gateway) resource derived from a
+[GatewayClass](/api-types/gatewayclass). This Gateway deploys or configures the
 underlying network resources that it represents. Through the
 [Route Attachment Process](/concepts/api-overview#attaching-routes-to-gateways)
 between the Gateway and Routes, the cluster operator and specific teams must
 agree on what can attach to this Gateway and expose their applications through
-it. Centralized policies [such as TLS](/v1alpha2/guides/tls#downstream-tls) can
+it. Centralized policies [such as TLS](/guides/tls#downstream-tls) can
 be enforced on the Gateway by the cluster operator. Meanwhile, the store and site
-teams run [in their own Namespaces](/v1alpha2/guides/multiple-ns), but attach their
+teams run [in their own Namespaces](/guides/multiple-ns), but attach their
 Routes to the same shared Gateway, allowing them to independently control
-their [routing logic](/v1alpha2/guides/http-routing). This separation of concerns
+their [routing logic](/guides/http-routing). This separation of concerns
 allows the store team to manage their own
-[traffic splitting rollout](/v1alpha2/guides/traffic-splitting) while
+[traffic splitting rollout](/guides/traffic-splitting) while
 leaving centralized policies and control to the cluster operators.
 
 ![Gateway API Roles](./images/gateway-roles.png)

site-src/v1alpha2/references/policy-attachment.md → site-src/references/policy-attachment.md

@@ -28,23 +28,23 @@ Access is granted with RBAC - for example, anyone that has access to create a
 RetryPolicy in a given namespace can attach it to any resource within that
 namespace.
 
-![Simple Ingress Example](/v1alpha2/images/policy/ingress-simple.png)
+![Simple Ingress Example](/images/policy/ingress-simple.png)
 
 To build on that example, it’s possible to attach policies to more resources.
 Each policy applies to the referenced resource and everything below it in terms
 of hierarchy. Although this example is likely more complex than many real world
 use cases, it helps demonstrate how policy attachment can work across
 namespaces.
 
-![Complex Ingress Example](/v1alpha2/images/policy/ingress-complex.png)
+![Complex Ingress Example](/images/policy/ingress-complex.png)
 
 ## Policy Attachment for Mesh
 Although there is a great deal of overlap between ingress and mesh use cases,
 mesh enables more complex policy attachment scenarios. For example, users may
 want to apply policy to requests from a specific namespace to a backend in
 another namespace.
 
-![Simple Mesh Example](/v1alpha2/images/policy/mesh-simple.png)
+![Simple Mesh Example](/images/policy/mesh-simple.png)
 
 Policy attachment can be quite simple with mesh. Policy can be applied to any
 resource in any namespace but it can only apply to requests from the same
@@ -55,7 +55,7 @@ workload to a backend in another namespace. A route can be used to intercept
 these requests and split them between different backends (foo-a and foo-b in
 this case).
 
-![Complex Mesh Example](/v1alpha2/images/policy/mesh-complex.png)
+![Complex Mesh Example](/images/policy/mesh-complex.png)
 
 ## Target Reference API
 
@@ -124,7 +124,7 @@ Each policy MAY include default or override values. Overrides enable admins to
 enforce policy from the top down. Defaults enable app owners to provide default
 values from the bottom up for each individual application.
 
-![Policy Hierarchy](/v1alpha2/images/policy/hierarchy.png)
+![Policy Hierarchy](/images/policy/hierarchy.png)
 
 To illustrate this, consider 3 resources with the following hierarchy: A
 (highest) > B > C. When attaching the concept of defaults and overrides to that,

site-src/v1alpha2/api-types

@@ -0,0 +1 @@
+../api-types

site-src/v1alpha2/contributing

@@ -0,0 +1 @@
+../contributing

site-src/v1alpha2/guides

@@ -0,0 +1 @@
+../guides