rh-ee-smodeel floated this as a possible step to move towards OTA-1322's target skew, without going as far as N+3 skew.  As with OTA-1322, the minimum dev change for this would be the Kube API server folks softening their existing Upgradeable guard, which currently allows 4.y.even to 4.y.(even+2) skew, but blocks 4.y.odd to 4.y.(odd+2) skew.

On top of that softening, we might want to backport knowledge about 4.17 to 4.15.z, so those releases could give cluster admins some heads up about what was expected in 4.17. For example, the Kube API server folks currently have APIRemovedInNextReleaseInUse and APIRemovedInNextEUSReleaseInUse alerts, to warn users about APIs removed in the next release (4.(y+1)) and in the next EUS release (4.(even>y)). That would warn someone running 4.16 about alerts removed on 4.17 (APIRemovedInNextReleaseInUse) and 4.18 (APIRemovedInNextEUSReleaseInUse). But we don't currently have an alert telling someone on 4.15 about Kube APIs removed in 4.17 (APIRemovedInNextNextReleaseInUse? Or APIRemovedInFutureReleaseInUse with a label about which release the API would be removed in?). And Kube API server isn't the only component with this kind of knowledge-of-future-releases backporting. OCPBUGS-43703 recently added a DuplicateTransferEncodingHeadersDetected alert to 4.12.z to warn users about 4.14 changes in that space, and the vSphere CSI operator added admin-acks to 4.12 (OCPBUGS-18131) and 4.13 (OCPBUGS-18132) to warn about changes coming in 4.14. Trying to audit this kind of thing from a cluster-scoped level is hard, but we could announce internally the coming channel change, suggest components backport 4.17 information to 4.15, wait a declared amount of time, and then add 4.15.z to the *-4.17 channels. We might not get 4.15 backports of all the 4.17 warnings we'd like, but we don't have to be perfect; anything that gets missed will still get reported on 4.16 as usual, and folks can just sort out any warnings 4.16 reports before updating to 4.17.