[FEAT] Introduce Plugin Stability Lifecycle (Alpha, Beta, Stable) and Dependency Validation

[liu-cong]

Problem Statement & Motivation

Currently, plugins in llm-d-router (pkg/epp/framework/plugins/) lack formal stability categorization (Alpha, Beta, Stable). For backwards-incompatible changes or deprecations, the project currently relies on ad-hoc logging and manual README updates across minor releases. Furthermore, there is currently no mechanism to prevent a production/stable plugin from depending on an experimental/alpha plugin or data key.

To provide clear compatibility guarantees to users and maintainers, we propose introducing a Plugin Stability Lifecycle (Alpha, Beta, Stable) with code-level, document-level, and dependency-level enforcement.

• Alpha: Rapid experimentation, breaking changes anytime, no deprecation period.
• Beta: [Current policy] Feature-complete; breaking changes follow a formal +2 minor version deprecation policy (warn in release $N$ and $N+1$, remove in $N+2$).
• Stable: Enterprise-grade; breaking parameter or behavioral changes only occur on major EPP version bumps.

[shmuelk]

@liu-cong wrote:

Rule: Higher-stability plugins cannot depend on lower-stability plugins:
Consumer Stability ≤ Producer Stability

The ConsumerPlugins are not the only plugins that depend on other plugins. The disaggregation plugins also depend on other plugins (the deciders).

I'm not sure this is such a good idea as it will prevent new ProviderPlugins that provide the same information from new sources. In the case of the disaggregation plugins, it would prevent new deciders from being used.

I agree that it should be clearer to the users which plugins are experimental (alpha or beta) vs those that are "production". In addition it is a good idea to somehow make sure that user is making a informed decision.

Perhaps what is needed is a feature gate of sorts where the user has to more explicitly state they are willing to use the experimental plugins...

[liu-cong]

Perhaps what is needed is a feature gate of sorts where the user has to more explicitly state they are willing to use the experimental plugins...

A feature gate makes sense. EPP only loads experimental plugins when the feature gate is enabled.

[ishwar170695]

One question about the proposed Plugin interface change: adding Stability() would require every plugin implementation (including any external ones) to implement the new method.

Is that API break intentional, or was the idea to treat stability as registration metadata instead?

Since the proposal already mentions storing stability in the registry, I'm wondering if that could avoid expanding the runtime interface while still enabling dependency validation and documentation.

[liu-cong]

Is that API break intentional, or was the idea to treat stability as registration metadata instead?

@ishwar170695 Right, I think treating it as a metadata in the plugin registry also works.