update/add versions to specs

traffic-access-control.md

@@ -10,7 +10,7 @@ default. See [tradeoffs](#tradeoffs) for a longer discussion about why.
 
 ## Specification
 
-### TrafficTarget
+### TrafficTarget `v1alpha1`
 
 A `TrafficTarget` associates a set of traffic definitions (rules) with a
 service identity which is allocated to a group of pods.  Access is controlled
@@ -34,7 +34,7 @@ To understand how this all fits together, first define the routes for some
 traffic.
 
 ```yaml
-apiVersion: v1beta1
+apiVersion: v1alpha1
 kind: HTTPRouteGroup
 metadata:
   name: the-routes

traffic-metrics.md

@@ -1,4 +1,4 @@
-# Traffic Metrics
+# Traffic Metrics `v1alpha1`
 
 This resource provides a common integration point for tools that can benefit by
 consuming metrics related to HTTP traffic. It follows the pattern of
@@ -205,13 +205,13 @@ The `traffic.metrics.k8s.io` API will be exposed via a `APIService`:
 apiVersion: apiregistration.k8s.io/v1
 kind: APIService
 metadata:
-  name: v1beta1.metrics.smi-spec.io
+  name: v1alpha1.metrics.smi-spec.io
 spec:
   group: metrics.smi-spec.io/v1alpha1
   service:
     name: mesh-metrics
     namespace: default
-  version: v1beta1
+  version: v1alpha1
 ```
 
 The default response, or requesting `/apis/metrics.smi-spec.io/v1alpha1/`

traffic-specs.md

@@ -1,4 +1,4 @@
-# Traffic Spec
+# Traffic Spec `v1alpha1`
 
 This set of resources allows users to specify how their traffic looks. It is
 used in concert with [access control](traffic-access-control.md) and other
@@ -48,7 +48,7 @@ extended at a later date to accommodate capabilities such as HTTP header,
 Host, etc.
 
 ```yaml
-apiVersion: v1beta1
+apiVersion: v1alpha1
 kind: HTTPRouteGroup
 metadata:
   name: the-routes

traffic-split.md

@@ -1,4 +1,4 @@
-# Traffic Split
+# Traffic Split `v1alpha2`
 
 This resource allows users to incrementally direct percentages of traffic
 between various services. It will be used by *clients* such as ingress
@@ -24,7 +24,7 @@ different selector and type. Weights must be whole numbers.
 ## Specification
 
 ```yaml
-apiVersion: split.smi-spec.io/v1alpha1
+apiVersion: split.smi-spec.io/v1alpha2
 kind: TrafficSplit
 metadata:
   name: my-trafficsplit
@@ -170,7 +170,7 @@ In order to update an application, the user will perform the following actions:
 * Create a new traffic split named `foobar-rollout`, it will look like:
 
     ```yaml
-    apiVersion: split.smi-spec.io/v1alpha1
+    apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
     metadata:
       name: foobar-rollout
@@ -203,7 +203,7 @@ At this point, the SMI implementation does not redirect any traffic to
   TrafficSplit resource:
 
     ```yaml
-    apiVersion: split.smi-spec.io/v1alpha1
+    apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
     metadata:
       name: foobar-rollout
@@ -226,7 +226,7 @@ At this point, the SMI implementation does not redirect any traffic to
   new version by updating the TrafficSplit resource:
 
     ```yaml
-    apiVersion: split.smi-spec.io/v1alpha1
+    apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
     metadata:
       name: foobar-rollout
@@ -266,7 +266,7 @@ At this point, the SMI implementation does not redirect any traffic to
 * TrafficSplits cannot be self-referential - consider the following definition:
 
     ```yaml
-    apiVersion: split.smi-spec.io/v1alpha1
+    apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
     metadata:
       name: my-split
@@ -305,7 +305,7 @@ object operates. It is not intended to prescribe a particular implementation.
 Assume a `TrafficSplit` object that looks like:
 
 ```yaml
-    apiVersion: split.smi-spec.io/v1alpha1
+    apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
     metadata:
       name: my-canary