Graduate the VinylCache API from v1alpha1 for 1.0 #122

Activity

1. jensens

   added

   enhancementNew feature or requestNew feature or request

   on Oct 25, 2026
2. jensens

   added this to the 1.0 milestone on Oct 25, 2026
3. jensens commented on Oct 25, 2026

   

   jensens

   on Oct 25, 2026

   MemberAuthor

   More actions

   Plan

   Decision: graduate to v1 directly, not v1beta1. 1.0 is the stability promise, and the 1.1 flavor field is additive, which v1 allows.

   Shape

   • New package api/v1. It is a copy of the v1alpha1 types and becomes the storage version (+kubebuilder:storageversion).
     • v1alpha1 stays served for the 1.x series, marked deprecated with +kubebuilder:deprecatedversion and a warning that points at v1.
   • Identical schemas, conversion None. The API server only rewrites apiVersion, so no conversion webhook is needed.
     • The price: while v1alpha1 is served, every schema change goes into both packages. A field that only v1 had would be pruned when read or written through v1alpha1, and a v1alpha1 client would silently drop it.
     • A test asserts that both generated schemas are equal, so the two packages cannot drift.
   • Webhooks register for v1 only, with matchPolicy: Equivalent (the default), so requests for v1alpha1 are converted and validated by the same code.
   • The operator, generator, webhook and controller switch to the v1 types. E2E fixtures and docs move to apiVersion: vinyl.bluedynamics.eu/v1. One fixture stays on v1alpha1 to prove the old version still admits and reconciles.
   • Stored objects: existing objects stay encoded as v1alpha1 in etcd until their next write, and status.storedVersions keeps listing v1alpha1.
     • Dropping v1alpha1 later (2.0) needs a storage migration first.
     • The operator can make that trivial by rewriting each object once, because reconcile already writes status. I would only note this here, not build it now.

   Order

   This lands after #121, #124, #126 and #127, because each of them changes the API types or the CRD, and this PR duplicates both.

   Outside this repo

   cdk8s-plone generates its import from the CRD and keeps working against v1alpha1. Moving it to v1 is a follow-up there, not a blocker for 1.0.

   Assisted-by: Claude Opus 5.5
4. jensens

   closed this as completedin #128on Oct 27, 2026