The intermediate OCP major release versions with channel names should be presented to the cluster administrator when upgrading from the preceding to the latest OCP major release.

1. Proposed title of this feature request

--> The intermediate OCP major release versions with channel names should be presented to the cluster administrator when upgrading from the preceding to the latest OCP major release.

2. What is the nature and description of the request?

--> If the customer is planning to upgrade the cluster to the latest major release available with multiple intermediate major release hops, he should be presented with the entire upgrade path (respective to the selected channel like stable or fast) to the latest major version with intermediate major versions.  

For example, if a customer is on 4.7.x and wants to upgrade to 4.10.y then when he executes the upgrade either from UI or CLI, he should be able to select 4.10.y version (maybe temporarily?) and then he should be presented with the entire upgrade path along with the channels that need to be updated with every major release hop. And then he can go ahead with an actual upgrade process.

OR we should at least provide a warning or banner to the cluster administrator via CLI and UI that they must check the upgrade paths to the next major releases. Maybe using a hyperlink to the OCP upgrade lab to verify the paths. 

This informational feature is already available on the Red Hat OpenShift Container Platform Update Graph Lab. One such example can be seen here: https://access.redhat.com/labs/ocpupgradegraph/update_path?channel=stable-4.6&arch=x86_64&is_show_hot_fix=false&current_ocp_version=4.6.51&target_ocp_version=4.10.16

3. Why does the customer need this? (List the business requirements here)

--> We have had an escalation from one of the strategic core banking customers stuck to the latest minor version from where they did not have any upgrade paths available to go to the next major release and ended up on the EOL release. 

In most cases, to avoid downtime, customers plan upgrade activity well in advance however, when they perform the actual upgrade during the scheduled maintenance window after a couple of days/week, they see a new minor version available and they unknowingly upgrade the cluster to it resulting in a situation where there is no upgrade path available to the next major release as the recently released minor versions take weeks of time to provide with an upgrade path via the stable channel.

4. List any affected packages or components.

--> Over the Air (OTA) OCP upgrades.