Goal

We want increase visibility for API depreciations.

Context

In #2869 we've identified a slight API change (bug). A change in behavior should be implemented eventually. We've identified that we don't have a agreed-upon "process" on how to announce, implement and release such API changes.

In our Depreciation Policy we define the scope as follows:

• API Objects and fields: .Spec, .Status and .Status.Conditions[]
• Enums and constant values
• Controller Configuration: CLI flags & environment variables
• Metrics as defined in the Kubernetes docs
• a specific feature or behavior:
  • ExternalSecret update mechanics

Acceptance criteria

• get more data: find other cases which require API changes or removals
  • potential provider depreciation
  • individual feature depreciated or breaking change in behaviour #2869
  • conversion strategy #1381
  • AWS SM/PS GetAllSecrets() using tags (logic OR vs AND) #698
• propose and discuss a process for these kind of changes
• implement admission warnings for all CRDs (e.g. via validation interface) feat: allow provider to return admission warnings #3058
  • implement cases found in [1] above, including the issue described in #2869
• implement automation such that in a PR can contain release notes, similar like other projects do it
• TBD