[NO-JIRA]: Add plugins doc section on Console version compatibility

[vojtechszocs]

Summary by CodeRabbit

• Documentation
  • Added Console version compatibility guidance for dynamic plugins, covering strategies for managing single and multiple Console versions per code branch with pros, cons, and implementation examples.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS [vojtechszocs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8efe80a2-fc35-4c8f-a48e-65b57a7633d0

📥 Commits

Reviewing files that changed from the base of the PR and between 21101de and 3d8213c.

📒 Files selected for processing (1)

• frontend/packages/console-dynamic-plugin-sdk/README.md

---

📝 Walkthrough

Walkthrough

This change adds documentation to the Console dynamic plugin SDK README outlining version compatibility strategies for plugin developers. It introduces guidance for two approaches: maintaining separate code branches targeting specific Console versions, or supporting multiple Console versions within a single branch. The documentation includes examples, trade-offs, and recommendations for plugin SDK versioning and CI configurations. The content is duplicated across two locations within the README. No code modifications or behavioral changes are included.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding documentation about Console version compatibility strategies for dynamic plugins.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[vojtechszocs]

@jseseCCS Hi, can you please review this docs change?

[logonoff]

/label px-approved

[vojtechszocs]

/retest

[openshift-ci]

@vojtechszocs: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[jseseCCS]

Bc this one needs various deep/far-reaching changes, I'd like to see a second draft after you consider my comments. thanks!

[jseseCCS]

the way this reads, it's not clear what's "listed below": the strategies or the projects. suggested rewrite:

"To make your plugin compatible with various Console versions, adopt one of the strategies listed below."

("range of" sounds salesy.)

[jseseCCS]

"and adapt your code" how?

need comma after "shared modules"

if we're asking users to adapt their code in plugin APIs and shared modules, what's meant by "and PatternFly support."?

[jseseCCS]

140-142 suggested rewrite for clarity and style rules:

Create a code branch for each supported Console version. For example, create a release-4.21 branch for use with Console 4.21. Build the plugin with the Console 4.21 SDK packages. In the plugin metadata, make sure that if there is a @console/pluginAPI dependency, it also supports any earlier Console versions that must load the plugin.

[jseseCCS]

No need to name a con unless we're declaring it as a bug.

GLOBAL: We need to make a decision about how we refer to the OCP console. I looked at the 4.21 docs again and this is what seems to be the approved approach:

• "OpenShift Container Platform web console" at first mention (in any content that could be standalone)
• "web console" after that
• "RHOCP" yes
• "OCP" no

Note:

• includes "web"
• both "web" and "console" lowercase

Also, according to the RH OPL, we can say "RHOCP" but not "OCP." (See Market products sheet, row 33.)

Generally, I'm a believer in consistency first, correctness second. By that I mean (btim), whatever we/they say most often is what we should also say most often. Either way, we need to pick a "first mention, next mentions" approach and commit to it. who's the decider?

144-149 suggested rewrite:

Set up CI and related workflows so that changes in your release-4.21 branch are tested on a cluster running OpenShift Container Platform Console 4.21. Apply the same approach for each supported Console version. When deploying the plugin to a cluster, use the plugin version that matches the Console version. This approach ensures that the plugin uses the same API version as the Console, avoiding compatibility issues between plugin code and Console APIs.

[jseseCCS]

155-158 suggested changes:

In the main development branch, use the Console plugin SDK package version that matches the oldest Console version your plugin supports. This approach relies on newer Console versions continuing to support plugins built for earlier versions unless the version gap becomes too large. For example, using the Console 4.19 plugin SDK package enables the plugin to target Console versions 4.19 through to the latest version.

when is the version gap too large? if i ask, some users will too.

[jseseCCS]

per style guides, use "for example" instead of "e.g."

--> "...range, for example, >=4.19.0-0."

[jseseCCS]

163-168 SR:

Set up CI and related workflows to test the plugin on all supported Console versions. When deploying the plugin to a cluster, verify that the OCP Console version falls within the supported Console version range. This approach uses a single development branch and avoids maintaining separate branches for different Console versions.

what's the "supported...version range"?

[jseseCCS]

not sure if this line is exposed to users or not, but just in case, SR:

Any shared modules from the Console that do not have a plugin fallback are listed as optional peerDependencies.