And I guess you've never been bitten in the ass by an ECS version upgrade that makes a bunch of your complex manifests break by removing support for apiVersions

And I guess you've never been bitten in the ass by an ECS version upgrade that makes a bunch of your complex manifests break by removing support for apiVersions, or deprecating features that you use? Because that happened with k8s 1.22, 1.24, 1.25... also, k8s releases have accelerated recently, so an upgrade gives you less time between potentially breaking changes that might require you to revisit long horrible yaml files that you hoped you'd never have to look at again. I know a guy running a startup, and his product and/or CICD pipeline has been broken twice by EKS upgrades. He had originally contacted someone in to build out a robust, scalable, self-healing infra 2 years ago. He then continued to work on the product code himself. Be didn't realise that the infra code would rot so badly until a forced EKS cluster upgrade broke stuff. He had no idea where to start. There isn't an easy upgrade path from 1.1x to 1.27. I told him he might be better off thinking of it a disaster recovery, ie: get his data across to a new cluster, bootstrapped with the latest charts for cert-manager, external-dns, nginx-ingress etc. In many cases he could `helm get values -n $namespace $release` and install the latest chart with the backed up values.