Update on BETA API changes

Modify the Implementation approach
Update Status fields

ships/0035-beta-api-changes.md

@@ -15,8 +15,8 @@ approvers:
   - "@SaschaSchwarze0"
   - "@adambkaplan"
 creation-date: 2022-07-09
-last-updated: 2023-03-10
-status: implementable
+last-updated: 2023-08-21
+status: implemented
 ---
 
 # Shipwright BETA API Release
@@ -119,19 +119,18 @@ From the above, the implementation can be categorize in two areas:
 
 #### Webhook Implementation
 
-1. We need to implement a webhook, following the [webhook](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/webhook/conversion) controller-runtime package. This webhook should assume that the related API types implement the conversion interface definitions. For the implementation, we propose to define the webhook as an additional deployment. This deployment could serve in the future additional endpoints for other types of admission requests.
+1. We need to implement a webhook for conversion. To achieve this, we will introduce a new deployment, which will run the webhook code and expose a `/convert` endpoint, in order for CRD's to use. CRD's then will use the webhook service as documented in [Configure CustomResourceDefinition to use conversion webhooks](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#configure-customresourcedefinition-to-use-conversion-webhooks) to be able to convert their Custom Resources. This webhook besides invoking the conversion functions for the different CR types, will handle a `ConversionReview` request and will return conversion results wrapped in `ConversionResponse`.
 
 #### API types and conversion functions
 
-1. Decide on the storage version. Here we propose to make _v1alpha1_ the storage version. This makes the _v1alpha1_ the "hub".
+1. Decide on the storage version. Here we propose to make _v1alpha1_ the storage version. This makes the _v1alpha1_ the "hub", meaning we convert to and from it.
 2. Add the _v1beta1_ API types, under [apis/build](https://github.com/shipwright-io/build/tree/main/pkg/apis/build)
 3. Introduce `<resource_name>_conversion.go` files next to the types, here we will define functions for conversion. This applies to all API versions.
-4. For the hub, we will introduce under the `*_conversion.go` file a `Hub()` function. This will be done for the _v1alpha1_ API version.
-5. For the spokes, we introduce under the `*_conversion.go` a `ConvertTo()` and `ConvertFrom()` function. This will be done for the _v1beta1_ API version.
-6. Populate the conversion functions, to adhere to the API changes and deprecations mentioned above.
-6. Modify the CRDs, to explicitly state which API version must be stored and which not.
-7. Regenerate all artifacts, from generated code to CRDs based on the new API types.
-8. Ensure that helper scripts for autogenerating are aware of the _v1beta1_ type.
+4. Introduce a `webhook` pkg, which will be hosting the `Conversion` interface and the implementation behind the `/convert` endpoint.
+5. For both _v1alpha1_ and _v1beta1_, the CR types should implement the `Conversion` interface, by adding a `ConvertFrom()` and `ConvertTo()` function.
+6. Populate the conversion functions for _v1beta1_ and _v1alpha1_ types, to adhere to the API changes and deprecations mentioned above.
+7. Regenerate all artifacts, from generated code to CRDs based on the new API types. Ensure the CRDs are updated with the `spec.conversion` block using the `/convert` endpoint and the proper webhook service. Ensure the CRDs explicitly state which API version must be stored and which not.
+8. Ensure that helper scripts for autogenerating are aware of the _v1beta1_ type. That a CABundle is autogenerated for the CRD's, etc.
 
 
 Note: We do not need to modify shipwright business logic or test cases, as they currently use the _v1alpha1_ API version. However, once the _hub_ API version is modified, we will need to modify this accordingly.