Epic Goal

Contrary to SemVer expectations, 4.22 to 5.0 updates are not expected to include backward incompatible changes that require clusters to be re-installed. In order to support those updates, the predicted DeploymentConfig removal version of 4.10000 (also a few other places in that file) should be bumped to... something... Possibly 6.0.0? Possibly 7.0.0 or later?

This should happen early in 4.22 development, and possibly get backported to older 4.y patch releases, in order to reduce possible user confusion vs. 5.0 expectations.

Why is this important?

Users should be able to update from 4.22 to 5.0 with an experience similar to existing 4.y to 4.(y+1) updates, including the expectation that DeploymentConfigs will survive at least through the OCP 5 release series.

Scenarios

A 4.22 cluster running oc get deploymentconfigs or oc adm inspect clusteroperators or similar should no longer see:

Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+

Instead they should see that deprecation message, but with an expected removal version that is greater than or equal to 6.0.0.

Dependencies

No dependencies outside the API repository and... whatever it is that brings the DeploymentConfig CRDs from the API repository into the cluster. Doesn't seem to be a release-image manifest:

$ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.21.0-ec.3-x86_64
$ grep -r DeploymentConfig manifests
...no hits...

Contributing Teams

• Development - WRKLDS
• Documentation - maybe a release note? The 4.14 release note did not commit to a specific removal version, but a 4.22 release note explicitly committing to DeploymentConfig existence through at least the newly-selected removal target might comfort customers?
• QE - WRKLDS
• PX - not required
• Others - not required

Acceptance Criteria

A 4.22 cluster running oc get deploymentconfigs or oc adm inspect clusteroperators or similar should no longer see:

Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+

Instead they should see that deprecation message, but with an expected removal version that is greater than or equal to 6.0.0.

Drawbacks or Risk

Committing to a removal version is hard. You want to be able to do it well in advance, to give the fleet a reasonable time to transition to the newer APIs. If you go too short, users have a squashed migration window, and it can be hard to turn around if users have to work through multiple levels of vendors/maintainers to get tooling updated. If you go too long, or predict a target and then slip, folks stop taking your predictions seriously and can assume support will continue forever, and then be surprised (and back to the too-short migration window) when you actually stick to your prediction. Going too long also increases the cost of maintenance for the team backing the deprecated feature, and increases the cognitive overload and communication costs in users who have to worry about whether their colleagues will use the old or new API.

Done - Checklist

• CI Testing - Tests are merged and completing successfully
• Documentation - not required
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Engineering Stories Merged
• All associated work items with the Epic are closed
• Epic status should be “Release Pending”