What problem are you facing?
The CLI has no documented maintenance policy. Core Crossplane has one (https://docs.crossplane.io/latest/learn/release-cycle/ quarterly cadence, three most recent minors maintained, roughly nine months per release), but nothing on that page or anywhere else covers the CLI specifically.
This surfaced concretely in a docs PR removing the CLI v2.2 release notes page. Two defensible positions, no rule to decide between them:
crossplane/crossplane#7350 partially covers this: it states that CLI minors are cut for substantial changes and alongside each core minor, and that only the two most recent CLI minors are supported. That PR is still open, lives in c/c rather than here, and addresses CLI-to-core compatibility rather than which CLI versions we maintain and document.
How could Crossplane help solve your problem?
Land an explicit policy and publish it in the docs. Specifically:
1. CLI support window. How many CLI minor versions are maintained, or over what period? Options: two most recent CLI minors (per #7350), three to mirror core, or a time-based window (nine months, as core effectively provides). Whichever we pick needs to hold when the CLI releases off core's cadence.
2. Patch and backport policy. Which CLI branches receive backports, and under what criteria. Core's "eligible for backporting to any maintained release branch" is a reasonable starting point.
3. Docs retention rule. Which CLI versions keep a docs entry. Proposal: retention follows the CLI support window, with a transitional carve-out for CLI versions that shipped inside core (v2.3 and earlier) those stay until their corresponding core version is EOL. That resolves the v2.2 case without tying future retention to core's cadence.
4. Compatibility matrix. A published table of CLI version to supported core versions, derived from the rules in #7350. Today users have to read a design doc to work this out.
5. Where the policy lives. Either a section on the existing core release cycle page or a dedicated CLI page under docs.crossplane.io/cli/. The core page is where people will look first, so a CLI section there with a link to fuller detail probably works best.
What problem are you facing?
The CLI has no documented maintenance policy. Core Crossplane has one (https://docs.crossplane.io/latest/learn/release-cycle/ quarterly cadence, three most recent minors maintained, roughly nine months per release), but nothing on that page or anywhere else covers the CLI specifically.
This surfaced concretely in a docs PR removing the CLI v2.2 release notes page. Two defensible positions, no rule to decide between them:
crossplane/crossplane#7350 partially covers this: it states that CLI minors are cut for substantial changes and alongside each core minor, and that only the two most recent CLI minors are supported. That PR is still open, lives in c/c rather than here, and addresses CLI-to-core compatibility rather than which CLI versions we maintain and document.
How could Crossplane help solve your problem?
Land an explicit policy and publish it in the docs. Specifically:
1. CLI support window. How many CLI minor versions are maintained, or over what period? Options: two most recent CLI minors (per #7350), three to mirror core, or a time-based window (nine months, as core effectively provides). Whichever we pick needs to hold when the CLI releases off core's cadence.
2. Patch and backport policy. Which CLI branches receive backports, and under what criteria. Core's "eligible for backporting to any maintained release branch" is a reasonable starting point.
3. Docs retention rule. Which CLI versions keep a docs entry. Proposal: retention follows the CLI support window, with a transitional carve-out for CLI versions that shipped inside core (v2.3 and earlier) those stay until their corresponding core version is EOL. That resolves the v2.2 case without tying future retention to core's cadence.
4. Compatibility matrix. A published table of CLI version to supported core versions, derived from the rules in #7350. Today users have to read a design doc to work this out.
5. Where the policy lives. Either a section on the existing core release cycle page or a dedicated CLI page under docs.crossplane.io/cli/. The core page is where people will look first, so a CLI section there with a link to fuller detail probably works best.