Caproni compatibility
Xianyun reads existing Caproni projects without changes.
| Caproni name | Xianyun name | Behaviour |
|---|---|---|
caproni.yaml | xianyun.yaml | Either works. If both are in one directory, xianyun.yaml wins. |
caproni.local.yaml | xianyun.local.yaml | Same rule |
caproni-project.yaml | xianyun-project.yaml | Same rule |
extends: files named caproni.<name>.yaml | xianyun.<name>.yaml | Both are accepted |
CAPRONI_CLUSTER_NAME and two more | XIANYUN_CLUSTER_NAME and two more | Same values |
CAPRONI_NO_CACHE | XIANYUN_NO_CACHE | Both are read |
~/.local/share/caproni | ~/.local/share/xianyun | The old location is read as a fallback |
What changed, with no alias
Names inside the cluster are new. The cert-manager ClusterIssuer and its Secret are called xianyun-ca, not caproni-ca, and the default profile name is xianyun. If your manifests or flags reference caproni-ca, update them. The repository’s examples/own-infrastructure.yaml still passes --default-issuer-name=caproni-ca and needs the same change.
Still says Caproni
A few strings weren’t renamed: the CA’s common name is “Caproni Dev CA”, the kubeconfig backup ends in .caproni.bak, and parts of --help and xianyun version say Caproni. Two code paths (the k3d and colima drivers) still build the old .local/share/caproni path, so state can land in either directory. These are listed in Known limitations.
Why the split was made is in ADR-0003.