Patternfly is releasing the new PF5 version. OCP console will implement support for plugins to bring their own PF4 or PF5

• We need to loosten the restriction for singleton pf library. 
• How do we differentiate the packages amongst the different packages
  • Would pf5 package names have to change? or can we handle this in code?
• If we are targeting muiltiple openshift versions can we target the lowest version of pf?
• We don't want plugins to have to support multiple versions.
• Can we avoid duplicate pf versions when supplied with several pf versions amongst plugins
• We should confirm there are no CSS conflicts.

Based on the discussion so far, the consoledot team was facing the same challenge with supporting both pf4 and pf5 versions. Lets talk with mmarosi123 about the challenges they have been facing.

AC:

• Ease shared module singleton restriction, so plugins can bring either pf4 or pf5
• Choose which particular version of pf4 and pf5 we to allow for the plugins to get loaded
• Update console-dynamic-plugin-sdk accordingly
• Test that a dynamic plugin with pf4 works when console updates to pf5

Additional notes:

• how would we guarantee that we use a single version of pf4 for all un upgraded plugins
  • is this possible through webpack make a single version of and pf5 and pf4 as a shared module
  • plugins shouldn't use a newer version in v5 than the console. can we enforce that or at least publish it?
  • can we use a single pf v4 and single pf v5
  • acm plugin supports current version -2 and +1 for their operator. what is the formula for plugins to bring their own plugin versions
  • bring on other plugin teams like cnv/acm for validation